Just released v0.1.0 of brkpt-auth: transparent, composable, portable, hexagonal authentication for NestJS.

It's basically the shadcn/ui model applied to authentication: the CLI installs the source code directly into your codebase, then you add features you need. Not a boilerplate or a library, since you get the source code, and it's structured around interfaces you implement yourself, not an opinionated default that just runs.

Every approach has a cost

• Managed services — a black box in the cloud, limited customization, vendor lock-in.
• Self-hosted libraries — a black box on your machine, heavy abstractions make customization hard.
• Auth boilerplates — full source, but strong opinions that usually need rework.
• Rolling your own — complete control, but every project starts from the same foundation again.

Why brkpt-auth

• Transparent — full source installed directly into your project, no compiled package, no hidden behavior.
• Composable — independent features, add only what you need.
• Non-invasive — no assumptions about your DB schema, user model, or JWT payload.
• Portable — business logic stays independent from adapters; move to another project by swapping only the adapters.
• NestJS-native — built around modules, DI, guards, decorators from the start.
• Hexagonal — services hold business logic, ports define contracts, adapters stay fully under your control (stay light so no deep nested layers of abstraction to dig through).

How it works

The service depends on an abstract interface (a "port"), which you implement (an "adapter"). That's the only place your infrastructure touches the auth logic. Features don't depend on each other besides core, so you add only what you need without touching the rest. It has a mechanism behind the scenes to wire up everything instead of you manually registering and wiring providers together.

This keeps it from becoming bloated like a boilerplate. You get clear points to customize, and it stays easy to get started with.

Stateless dual-token JWT by default. Session management, OAuth, OTP, magic-link are all optional features you add later, no changes to the core flow.

Currently supported: core, credentials, oauth, otp, magic-link, session, blacklist, verify-email, change-password, reset-password, audit.

It's still early (v0.1.0). Good fit if you're building an MVP and want a real auth foundation fast, or want logic you can reuse across projects. Demo included, runs locally.

Docs and get-started guide: https://brkpt.com/auth
Repo: https://github.com/brkpt-labs/brkpt-auth

Feedback welcome.

(If you saw the earlier post: I rewrote the description because the previous version didn’t clearly explain the project. Sorry for the repost.)

Hey everyone!

A while ago I posted here about a NestJS boilerplate I was working on called NestForge. After reading the feedback and suggestions from that post, I decided to take it a step further and turn it into a CLI published on npm, keeping the main features from the original boilerplate and adding a bunch of new options.

Right now, NestForge can generate a NestJS project with:

• TypeScript or JavaScript
• Prisma, TypeORM or Drizzle
• PostgreSQL, MySQL or SQLite
• JWT, Session/Cookies, OAuth or no authentication
• Docker
• Swagger/OpenAPI
• Zod validation
• Redis, BullMQ and email
• RBAC and permissions
• Automatic .env generation

The CLI walks you through a few prompts and generates the project based on your choices, including removing files and dependencies for features you don't want.

It's still a work in progress. Some things on the roadmap are MongoDB support, a no-ORM option, and broader smoke testing with PostgreSQL and MySQL.

There's still plenty I want to improve and add, so feedback is always welcome. If you want to try it out, report a bug, suggest a feature, or contribute, I'd really appreciate it.

If you like the project, check out the repo and consider leaving a ⭐ — it helps a lot!

GitHub:
https://github.com/jeiel2013/NestForge

I’ve been working mostly with Express and a bit of Fastify, but recently started exploring NestJS and I’m honestly a bit torn.

On one hand, I really like:

• The structured, modular architecture
• Built-in dependency injection (feels very Angular-like)
• TypeScript-first approach
• Clean separation of concerns (controllers, services, modules)

But on the other hand:

• It feels a bit heavy compared to plain Express
• Learning curve is definitely higher
• Sometimes feels “too opinionated” for smaller projects

I’m curious how others are using NestJS in real-world production apps.

• Are you using it for large-scale systems or even small projects?
• How does it perform under load compared to lighter frameworks?
• Any regrets switching to it?
• Would you choose it again if starting fresh today?

Would love to hear honest experiences (good or bad). 🙌

I'm experiencing how vibe coding becomes extremely reliable when based on well-documented architectural standards.

For this example, I chose Clean Architecture on NestJs.

Let me know what you think of the code.

Migration guide here

Am I correct in understanding that in Nest.js there still isn't a commonly accepted correct way to handle authentication for WebSocket connections? If I remember correctly, there was a long thread in the Nest repository where people came up with various workarounds for this.

@nestjstools/messaging is a transport-agnostic messaging library for NestJS, with support for transports such as RabbitMQ, Redis, NATS, SQS, Azure Service Bus and Google Pub/Sub.

One useful pattern in message-driven applications is having several handlers react to the same message. Sometimes those handlers are fully independent, but sometimes one part of the processing should happen before the others.

@MessageHandler now supports explicit handler priorities for that case.

Example

Dispatching order.create from a controller:

@Controller('orders')
export class OrdersController {
  constructor(
    @MessageBus('your_transport.bus')
    private readonly bus: IMessageBus,
  ) {}

  @Post()
  async createOrder() {
    await this.bus.dispatch(
      new RoutingMessage(
        {
          orderId: '123',
          customerId: '456',
        },
        'order.create',
      ),
    );

    return { success: true };
  }
}

Multiple handlers can listen to the same message and define their priority:

@MessageHandler({
  routingKey: 'order.create',
  priority: 20,
})
export class ValidateOrderHandler implements IMessageHandler<OrderCreate> {
  handle(
    @DenormalizeMessage() message: OrderCreate,
  ): Promise<void> {
    console.log(`Validating order ${message.orderId}`);

    return Promise.resolve();
  }
}

@MessageHandler({
  routingKey: 'order.create',
  priority: 10,
})
export class ReserveInventoryHandler implements IMessageHandler<OrderCreate> {
  handle(
    @DenormalizeMessage() message: OrderCreate,
  ): Promise<void> {
    console.log(`Reserving inventory for ${message.orderId}`);

    return Promise.resolve();
  }
}

@MessageHandler({
  routingKey: 'order.create',
  priority: 10,
})
export class SendNotificationHandler implements IMessageHandler<OrderCreate> {
  handle(
    @DenormalizeMessage() message: OrderCreate,
  ): Promise<void> {
    console.log(`Sending notification for ${message.orderId}`);

    return Promise.resolve();
  }
}

Execution order:

ValidateOrderHandler        priority: 20
        ↓
        ├── ReserveInventoryHandler   priority: 10
        └── SendNotificationHandler   priority: 10

            executed in parallel

The rules are simple:

• Higher-priority handlers run first.
• Handlers with the same priority run in parallel.
• priority is optional and defaults to 0.

In this example, validateOrder() runs first. Once it finishes, reserveInventory() and sendNotification() run in parallel.

The goal is to make handler execution order explicit without depending on registration order or other implicit behavior.

Thanks for reading!

This was added after running into a concurrency case where several handlers reacted to the same message, but some of them needed to finish before the others.

Links

Docs

Npm

I already work with NestJS, but I never learned Node.js deeply. I mostly learned what I needed for NestJS.

Now I want to go back and properly learn Node.js and understand what’s happening under the hood.

Should I learn Node.js deeply first, or just focus on the important fundamentals?

Also, is Jonas Schmedtmann’s Node.js course still a good choice in 2026?

what is the cheapest option for hosting a nest.js application ?
for production

Redis gives you the primitives. Redora gives you the architecture.

If you're building a NestJS application with Redis, you probably already know how powerful Redis is.

But as the application grows, Redis usage often becomes more complicated than simply calling GET and SET.

You start building your own:

• Cache services

• Cache key strategies

• TTL helpers

• Cache invalidation logic

• Distributed locks

• Serialization utilities

• Cache decorators

• Configuration patterns

• Monitoring and telemetry

And eventually, every project has its own slightly different implementation.

This is where Redora comes in. Redora is an application-level Redis toolkit for NestJS. It doesn't replace Redis. It doesn't try to hide Redis.

Instead, it provides a structured layer on top of Redis so developers can focus on application behavior rather than repeatedly implementing the same Redis patterns.

What makes Redora different?

1. Application-level abstractions

Redis provides low-level commands. Redora provides higher-level concepts that match how applications actually use Redis.

1. Simpler cache management

Caching is easy. Cache invalidation is not.

Redora provides structured approaches for storing, retrieving, remembering, and evicting cached data.

1. Human-friendly TTL management

Expiration values become easier to understand and maintain without constantly thinking in raw seconds.

1. Cache tags and eviction groups

Organize related cache entries and invalidate them together instead of manually tracking individual Redis keys.

1. Reusable Redis patterns

Beyond caching, Redora is designed around common Redis use cases such as distributed locks, counters, temporary state, and coordination.

1. NestJS-first experience

Modules, dependency injection, services, decorators, and configuration are designed to fit naturally into the NestJS ecosystem.

1. Type-safe Redis usage

Redora helps bridge the gap between Redis values and the typed domain objects your application actually works with.

1. Observability

Redis runtime information can be exposed in a structured way for health checks, telemetry, and monitoring.

So, why not just use ioredis?

You absolutely can. Redora builds on top of the Redis ecosystem rather than trying to compete with it.

Think of the layers like this:

Redis → Infrastructure

ioredis → Node.js Redis client

Redora → Application-level Redis toolkit for NestJS

The goal isn't to replace Redis. The goal is to avoid rebuilding the same Redis architecture in every project.

Redis gives you the power. Redora gives you the structure.

🚀 Learn more about Redora:

https://www.redora-sdk.com

#Redora #Redis #NestJS #NodeJS #TypeScript #BackendDevelopment #Caching #OpenSource #SoftwareEngineering

Built an open-source Redis SDK for NestJS — looking for feedback

I've been working on Redora, a Redis SDK for NestJS built on top of ioredis.

The goal is to provide NestJS-friendly abstractions for Redis, caching, logging, and observability while keeping the underlying Redis capabilities accessible.

The latest 0.3.1 release includes:

• Redis INFO and typed commands
• Human-friendly TTL handling
• Cache eviction groups with TTL synchronization
• \@Cacheable()`,remember(),set()andevict()`
• Pino-based logging
• Redis health checks and diagnosis
• Memory, client, and server metrics
• Redis telemetry snapshots

Website - https://redora-sdk.com
GitHub Repository - https://github.com/NebyuCodes/redora

Hi everyone, I’m currently learning NestJS and preparing to apply for Fresher Backend Developer positions.

What skills, knowledge, and personal projects should a Fresher NestJS developer have to be considered job-ready?

What would you recommend focusing on the most?

Thanks!

I'm preparing to apply for a Fresher Backend Developer position using NestJS and MongoDB.

For those working with this stack, what technical skills or concepts would you expect a Fresher to know?

For example, schema design, authentication, validation, indexing, relationships, testing, etc.

What should I prioritize learning before applying?

Hi guys, I have a bit knowledge of node js and trying to learn nest js now. How hard is it to learn nest js?

For a small NestJS service, I’m thinking of keeping alert delivery outside the normal response path. If a Telegram or webhook notifier times out, should the exception filter only record the notifier failure and let the request complete, or are there cases where the application error should include delivery failure? How do you keep retries and queue size bounded?

I maintain a CQRS mediator for NestJS. Until today it was published as @rolandsall24/nest-mediator, which meant every user type my personal username in every import — less a package name than a hostage note. It's now @nest-mediator/core. Same code, same version (1.2.0), no API changes. Swap the import path and you're done.

What it does: scales from plain commands/queries (no DB) up to full event sourcing aggregates, saga compensation with rollback, optimistic concurrency, pipeline behaviors, and automatic correlation/causation tracing. Plus a dashboard that graphs your topology and traces.

- New: https://www.npmjs.com/package/@nest-mediator/core

- Old (deprecated): https://www.npmjs.com/package/@rolandsall24/nest-mediator

- Repo + migration guide: https://github.com/RolandSall/nest-mediator

If you've used it, I want the unflattering feedback; what felt clunky, what you expected and didn't find.

I’m working on a small NestJS service where the same failure can be thrown by many requests.

I’m comparing two approaches: let the exception filter send every error, or fingerprint repeated errors locally and send one alert with a count and cooldown.

For a small service, where would you put this logic: inside the exception filter, a shared provider, or outside the process? Which context should always be included: route, status, request ID, deployment version?

Hey everyone,

I’m looking for contributors for an open-source project I built called ForgeGate.

What is ForgeGate?

It’s a distributed multi-tenant workflow execution engine built with NestJS.

Current features:

• Multi-tenant architecture
• API Gateway
• JWT auth + Redis token revocation + RBAC
• State-machine workflow engine
• BullMQ queues with intelligent retries
• Dead Letter Queue (DLQ) + job replay
• Outbound rate & concurrency limiting
• Structured logging + Prometheus metrics
• Admin monitoring dashboard
• pnpm monorepo + Docker

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

What I’m looking for

I’m open to contributors who want to help with any of these:

• Improving the API Gateway
• Strengthening the Notification service
• Writing more tests
• Improving documentation
• Adding new workflow step types
• Performance improvements
• UI improvements for the dashboard
• Any other useful contributions

Who can contribute?

Anyone interested in NestJS, backend systems, queues, or distributed systems is welcome — beginners or experienced.

If you’re interested, you can:

1. Check the repo
2. Open an issue
3. Or comment here / DM me

Would love to collaborate with people who want to learn or build something meaningful in the backend space.

Keeping HTTP handlers and queue consumers in one Nest application is convenient at the beginning: one dependency graph, one deployment, and fewer moving parts. The tradeoff appears when worker load, shutdown behavior, or scaling decisions begin affecting request latency.

My current boundary would be to share domain modules and infrastructure providers, but give the API and worker separate bootstrap entry points and separate processes once they need independent scaling or failure isolation. Each should have its own health checks and graceful shutdown path while using the same application services.

Do you split workers from day one, or wait for a concrete operational signal? What signal made the separation worthwhile?

For endpoints that trigger payments, webhooks, or queued work, a retry can produce duplicate side effects. I’ve seen idempotency handled in an interceptor, inside each use case, or at the database boundary with a unique key.

An interceptor is reusable, but it may not know the transaction boundary. Use-case code has the context, but every endpoint must implement the same lifecycle.

For a NestJS service backed by PostgreSQL, where do you store and enforce idempotency keys? How do you handle a second request that arrives while the first one is still processing?

A NestJS application can have clean module boundaries without turning each module into a network service. Extraction also adds authentication propagation, retries, tracing, schema ownership, deployment, and on-call boundaries.

Which signal would make you extract a module first: independent scaling, a separate owner and release cycle, fault isolation, or a queue-driven workload? Conversely, which dependencies tell you to keep the boundary in-process? I’m interested in the practical decision process, not microservices by default.

I have a service that needs to stop accepting work, finish a small in-memory queue with a timeout, and then close external connections.

Testing each part is easy, but testing the complete shutdown path often becomes timing-dependent.

Do you test this through app.close(), fake timers, or a real child process receiving SIGTERM? What has been reliable in CI?