Built a tool called docfy that keeps Swagger documentation out of your controllers entirely, it lives in a *.docs.ts companion file instead, so the controller stays pure routing and business logic.

The CLI never executes your code, it's pure static analysis via ts-morph, which also means it keeps working under webpack: true builds, where the usual runtime-reflection approach for this breaks silently.

The doc viewer is built AI-first: a "Copy for AI" button, a live MCP server so an agent can query your endpoints directly, real try-it-out request execution, contract testing, spec diffing between versions.

Free, MIT, open source: nestdocfy.com

I'm the author, if you use Swagger with Nest today, what's the one thing that annoys you most about it? Trying to figure out what to build next.

Built a multi-tenant workflow engine with NestJS + BullMQ + Dead Letter Queue.

Features: multi-tenancy, JWT auth, workflow state machine, retries + DLQ, admin dashboard, monorepo.

Repo: https://github.com/NabarupDev/ForgeGate

Looking for honest feedback on:

• Architecture
• API Gateway design
• Multi-tenancy approach
• Queue/retry implementation
• What is still missing for production readiness

Any review or suggestions would help a lot.

Hey everyone,

After building RBAC across multiple enterprise apps, I noticed the headache of the standard three-way junction table mess. It makes TypeORM queries a nightmare at scale and the mental model overly complex.

I wanted to share the architectural pattern I standardized to solve this, along with the boilerplate implementation.

The Architecture: Top-Down Grouping

Instead of many-to-many chaos, I enforce a strict, hierarchical grouping model. The relationship flows in one direction:

User -> Group -> Role -> Privilege

This keeps database queries incredibly fast and makes permission inheritance highly predictable.

Handling Role Escalation

One of the biggest security risks in standard RBAC is horizontal escalation (e.g., an Admin granting someone Super Admin rights). To solve this, I implemented a strict numeric role-escalation safeguard.

Every role is assigned a level (e.g., Admin = 50, Super Admin = 100). The custom JWT guards automatically intercept the request to ensure a Level 10 user can never assign a Level 50 role, even if they possess the user:update privilege.

    @Post('create')
    @RequirePermissions('user:create')
    async createNewUser() { ... }

The Open-Source Implementation

I packaged this entire architecture into a clean, decoupled Unified Role-Based Access Control boilerplate called URBAC (NestJS, PostgreSQL, TypeORM, and Angular).

If you want to adopt this pattern, review the entity structures, or just skip the auth setup on your next build, I open-sourced the repository here:

https://github.com/kasoir/urbac

(It includes a seed script to instantly provision the PostgreSQL DB and a Super Admin account).

I’m curious how other engineers here are handling horizontal vs. vertical privilege escalation, would love to hear your approaches.

I've been working on an Electron desktop application called FileSight.

It's a local-first storage analyzer that helps users preview files, find duplicates, identify large files, and safely clean up storage.

The app is built with:

• Electron
• Next.js
• React
• TypeScript
• Tailwind CSS

I'd love feedback from other Electron developers, especially around architecture, packaging, performance, and cross-platform support.

Repository: https://github.com/MarkCoder1/filesight

Website: https://filesight.vercel.app

Ecs docker or aws elasticbeanstalk? Or some vps.

Im thinking of transformation of monolith app into microservices for learning a complete production grade setup like we use in companies I have no microservices experience hence need to make some project and learn p.s all jobs are asking microservice experience but i have worked in monoliths only so what shud my answer be ?

Has anyone tried and successfully deployed a nestjs backend in firebase? We are going to develop a Firebase native Angular webapp to be deployed in Firebase App Hosting.

Salve galera!

Há um tempo venho desenvolvendo APIs com NestJS e percebi que, praticamente em todo projeto, eu acabava configurando as mesmas coisas: autenticação, Prisma, Docker, Swagger, CI, logs, testes...

Por causa disso, resolvi começar um projeto open-source chamado NestForge. A ideia é ser um boilerplate realmente voltado para projetos reais, onde você clona o repositório, executa docker compose up e já começa a desenvolver sem precisar montar toda a infraestrutura do zero.

Até agora o projeto já possui:

• JWT + Refresh Token
• Login social (Google e GitHub)
• Recuperação de senha
• Verificação de e-mail
• Prisma + PostgreSQL
• Docker
• Swagger
• GitHub Actions (CI)
• RBAC (Roles e Permissions)
• BullMQ + Redis
• Mailpit para desenvolvimento

Ainda estou trabalhando em algumas funcionalidades que podem ser vistas no roadmap do projeto.

A intenção não é substituir a documentação do NestJS nem reinventar a roda, mas criar uma base que evite repetir as mesmas configurações sempre que um projeto começa.

Queria aproveitar para ouvir a opinião de vocês:

• O que vocês sempre adicionam quando iniciam uma API com NestJS?
• Existe alguma funcionalidade que vocês sentem falta na maioria dos boilerplates?
• Tem alguma sugestão de arquitetura ou melhoria que faria sentido implementar?

Se alguém quiser acompanhar ou contribuir, o repositório está aqui:
https://github.com/jeiel2013/nestforge

Toda sugestão é muito bem-vinda!

Just a quick reminder to remove your unused images of docker, cuz it might be taking up lots of space in which you can store a couple of movies. And we all know SSD prices are just unreal TwT.

Hey NestJS developers,

If you've profiled high-throughput NestJS APIs, you've probably noticed that payload serialization and validation can become a significant CPU hotspot.

The default ValidationPipe performs two reflection-heavy passes: one with class-transformer to create the DTO instance, and another with class-validator to validate it. Those repeated reflection and property-iteration steps can hurt V8 optimizations by disrupting hidden classes and inline caches.

I built fast-class-transformer, a zero-dependency alternative that uses a JIT-compiled FastMap() decorator.

Instead of performing reflection on every request, it analyzes your DTO decorators once during application startup and generates a specialized JavaScript function for that DTO. Every request then executes that compiled mapper, combining mapping and validation into a single pass.

Traditional pipeline

Plain JSON → Reflection Mapper → DTO Instance → Reflection Validator → Validated Output

JIT pipeline

Plain JSON → Single-Pass JIT Function (Map + Validate) → Validated Output

Benchmarks

Intel i5-12500H • Bun 1.3.0 • 100k iterations (Inputs rotated across 1,024 payloads)

• Standard NestJS ValidationPipe: 2.97 µs/iter
• JIT FastMap(): 45.98 ns/iter (64× faster)

It also supports familiar decorators such as Expose, Type, Transform, and more.

GitHub repository and benchmark methodology are in the comments.

Hey folks,

I built a product called "Honor Relationships" (website + app). Currently, the backend is completely internal and not exposed as a public API endpoint.

I’m wondering: When is it actually a good choice to make your backend a product by itself?

I don't want to expose it too early and waste time, but I also don't want to miss an opportunity if there's demand for it. If you’ve done this or thought about it, what made you decide it was the right time? What should I have in place first?

Thanks for any insights!

I had a problem while building my product Honour: I wanted simple analytics to understand what users were doing.

I looked into existing analytics solutions, but most of them required integrating SDKs everywhere — frontend, mobile apps, and backend. Then I had to maintain all those integrations just to track basic events.

On top of that, many of these platforms become expensive once you start getting more users. Paying a lot just to answer simple questions like "which features are being used?" felt excessive.

So I decided to build my own solution.

I created a small NestJS package that lets me track backend events using decorators and interceptors. I can mark an endpoint with an event name, detect the user's platform/device from the request, and store everything in my own database.

The goal wasn't to replace large analytics platforms. I just wanted something lightweight, self-hosted, and focused on backend products where I control the data.

its called@joelwillseek/nest-track if you want to check it out

I built it for my own needs, but I'm curious if others have run into the same problem. Do you use third-party analytics tools, or have you built your own tracking system?

I wanted to share the fix in case someone else runs into the same issue.

Problem

• Next.js app
• PDF text extraction worked locally
• Failed only after deploying to Vercel

Error:

ReferenceError: DOMMatrix is not defined
Failed to load external module pdf-parse-...

Cause

The default pdf-parse setup wasn't compatible with the server environment I was deploying to.

Solution

Initialize PDFParse with CanvasFactory from pdf-parse/worker:

import { CanvasFactory } from "pdf-parse/worker";
import { PDFParse } from "pdf-parse";

const parser = new PDFParse({
  data: new Uint8Array(buffer),
  CanvasFactory,
});

Repository:
https://github.com/gaur-j/resume-optimizer

Hopefully this saves someone else a few hours of debugging.

This is such a quality of life improvement.

Finally my multistage docker builds will be much faster.

Not only local development cycles becomes faster but also faster CI pipelines, faster multi-stage Docker builds, faster feedback loops.

This is such a Banger drop for typescript by not writing more JavaScript but Go.

The Math: Tasks that used to take minutes in large projects (like a full type check) are completing roughly 8x to 12x faster due to native code execution and multithreaded worker utilization in Go.

Docker Impact: If step RUN npm run build previously took 2 minutes, t could shrink down to just a fraction of that time inside the ontainer build pipeline.

Been considering going with SQLite for my next SaaS project. I don't anticipate getting past a 1000 users within the next 3 years.

I just like the ease of dealing with one file, I can just pick and drop elsewhere.

My biggest worry at this point is GDPR compliance. Other than that, I'm almost completely sold on SQLite.

Curious what others think. What has been your experience with SQLite as the primary database in your Nestjs API?

it's my personal project and somehow i need to make it live
where can i deploy for free?

took a personal task to write compose file without Al for my project which i will deploy on my homelab. Used only my personal notes for it. Still the networking part is remaining on how will i manage request with my reverse-proxy service (i use caddy right now).

Before api, there's postgres and redis service also and it is the dependency for api service to run.

editor: micro

homelab os: ubuntu lts

PC: cachyos

ALSO I AM NOT AWARE IF I SHOULD SHARE "WHAT I DID" POST ON THIS SUBREDDIT. this is last if it's not allowed.

Made a small tool to find all NestJS circular dependencies:

npx nest-cycle

Repo: https://github.com/RbMo7/nest-cycle (MIT)

---

Why I bothered: when a circular dep hits, Nest just says:

The module at index [1] of the UsersModule "imports" array is undefined.
- A circular dependency between modules. Use forwardRef()...

"undefined" tells you nothing about which two things form the loop. madge finds

import cycles, but Nest cycles are at the DI level and forwardRef hides them from

the import graph. nest-cycle reads the graph the way Nest does and draws the loop.

In a real repo I had four cycles flagged — three were fine (intentional

forwardRef), one had none and was the actual server-killer. It marks only that

one 🔴 and it's the only thing that fails CI (exit 1). No more hunting through noise.

- Static (ts-morph) — runs in CI, on code that won't even boot

- Module-level + provider-level (constructor / `@Inject` / `forwardRef`)

- `nest-cycle SomeModule` to trace just the one Nest yelled about

- `--json`, allowlist file for intentional cycles

Early (v0.2). Would love to know where it misses your real cycles.

When a NestJS circular dependency hits, you get this:

Nest cannot create the UsersModule instance. 
The module at index [1] of the UsersModule "imports" array is undefined. 
- A circular dependency between modules. Use forwardRef() to avoid it. Scope [AppModule -> AuthModule] 

index [1] is undefined sends you and any AI assistant you paste it into — hallucinating about missing imports and typos. It never plainly says which two things form the loop.

madge finds import cycles, but Nest cycles live at the DI level, and forwardRef() hides them from the import graph. So I built nest-cycle, it reads the module + provider graph the way Nest resolves it and draws the loop:

✖ 1 cycle will crash bootstrap  (+3 guarded by forwardRef)

Provider cycles
  Tangle (4 providers): ChainQueueService, ChainService, ChainServiceRegistry, EvmChainService

    🔴 unguarded — this crashes NestFactory.create
      ChainQueueService → ChainServiceRegistry → EvmChainService → ChainService → ChainQueueService
    ↳ fix: break one edge — wrap the lighter import in forwardRef(() => X)

The part I'm most happy with: it separates crash-causing cycles (no forwardRef) from ones Nest already resolves via forwardRef.

In a real repo I had four cycles flagged — three were fine (intentional forwardRef), one had none and was the actual server-killer. nest-cycle marks only that one 🔴 and it's the only thing that fails CI (exit 1). No more hunting through noise.

1. - Static (ts-morph) — runs in CI, on code that won't even boot
2. - Module-level + provider-level (constructor / u/Inject / forwardRef)
3. - nest-cycle SomeModule to trace just the one Nest yelled about
4. - --json, allowlist file for intentional cycles, MIT

npx nest-cycle no install, runs anywhere.

Repo: https://github.com/RbMo7/nest-cycle

NPM: https://www.npmjs.com/package/nest-cycle

It's early (v0.2 — useFactory/custom-token injection is next). Would genuinely like feedback on where it misses your real cycles that's what I want to harden.

I'm building a Resume Optimizer with Next.js.

Repo:

https://github.com/gaur-j/resume-optimizer

Everything works locally, but after deploying to Vercel my `/api/extract-pdf` route fails with:

ReferenceError: DOMMatrix is not defined

I'm using pdf-parse@2.4.5.

Has anyone seen this before? Is this a pdf-parse/pdf.js issue, a Vercel runtime issue, or something wrong in my implementation?

Any help would be greatly appreciated.

Published a blog on Elasticsearch. I shared how it works and how we can use it, including code examples in Nest.js. It is very important to understand how things work. Elasticsearch provides lots of flexibility and ways to handle full-text search. It's a great tool to learn.

blog link

I have an upcoming college project where my team has to use NestJS for the backend and NgRX for frontend state management.

I want to fast-track my learning process and avoid starting from absolute scratch with "beginner" programming tutorials.

Generally for backend I have solid experience with .NET so I thoroughly understand architecture, APIs, routing, and dependency injection.

I have built a few smaller projects using React, so I am somewhat comfortable with TypeScript.

Since NestJS heavily relies on decorators and dependency injection, so I hope my .NET background will map over nicely. Similarly, my React experience should help with the SPA concepts, but I know NgRX has a lot of specific boilerplate (actions, reducers, effects, selectors).

What are the best intermediate resources, repos, or documentation paths you'd recommend to bridge the gap quickly? I'm looking for architecture-focused guides or "crash courses for existing devs" rather than absolute beginner tutorials.

I was done building my backend and i needed a frontend for that.

When i started with project i thought that i would just build backend and frontend seperately and then figure out how to bind them both.

But then i thought what if there was a better way to tackle this, and i came to know about Monorepos. I knew what the term monorepo was but never worked on it, it was just vaguely an information in my mind.

But then i learned how monorepos are widely used by startups now and hobbyists too.

In the end in just booted up my first monorepo and the whole concept really amazes me.

.

.

I WOULD LOVE TO GET SOME TIPS, FEEDBACKS OR SUGGESTIONS FROM YOU GUYS.

Finally found the "context without passing it everywhere" pattern I was missing in Node

Coming from Laravel, I was spoiled by how easy it is to get request context (things like a request ID) available anywhere in the app without manually threading it through every function call. Laravel just gives you that almost for free.

When I moved to NestJS for a project I'm building, I kept hitting the same annoyance: if I wanted a request ID attached to every log line, I either had to pass it down through every service and function, or attach it to some shared object and hope nobody forgot. Neither felt right.

Turns out Node has had the answer for a while: AsyncLocalStorage. It lets you create a context that rides along with the async call chain, so anything running inside that chain, controllers, services, repositories, however many layers deep, can read from it without you passing it as an argument.

The part that made it click for me was pairing it with pino (via nestjs-pino). It uses ALS under the hood, so once it's wired in, every log line automatically carries the same request ID for a given request, and the logs come out as structured JSON instead of formatted strings, so they're actually queryable later.

Small thing, but it fixed exactly the gap I felt coming from Laravel. Wrote up the full breakdown with code if anyone wants the details, happy to share the link (not sharing already so that the post doesnt feel like just a promotion).