> ## Documentation Index
> Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt
> Use this file to discover all available pages before exploring further.
# NestJS Mastery
> Build production-ready, scalable Node.js applications with NestJS
# NestJS Mastery
Master the most powerful Node.js framework for building enterprise-grade applications. This comprehensive course takes you from NestJS fundamentals to advanced patterns, teaching you to build scalable, maintainable, and production-ready backend systems.
Think of NestJS as bringing the discipline of enterprise frameworks like Spring Boot or ASP.NET to the Node.js world -- it gives you structure where Express gives you freedom, and that structure pays dividends the moment your team grows beyond two people or your codebase crosses a few thousand lines.
**Course Duration**: 10-12 weeks\
**Target Outcome**: Senior Backend Engineer\
**Prerequisites**: JavaScript/TypeScript, Node.js basics, REST API concepts
## What You'll Learn
By the end of this course, you'll be able to:
* Build scalable REST APIs and GraphQL endpoints with NestJS
* Implement robust authentication and authorization systems
* Design and deploy microservices architectures
* Write comprehensive test suites for your applications
* Deploy production-ready applications with Docker and Kubernetes
* Apply advanced patterns like CQRS, Event Sourcing, and WebSockets
* Optimize performance and handle real-world production challenges
## Course Structure
Core concepts, project setup, modules, controllers, and services
Deep dive into DI system, provider scopes, custom providers, and module patterns
Request handling, validation, middleware, guards, interceptors, and error handling
Service layer architecture, repository pattern, and domain-driven design
TypeORM and Prisma integration, migrations, transactions, and query optimization
JWT authentication, OAuth2, RBAC, password hashing, and security best practices
Unit, integration, and E2E testing strategies with mocking and CI/CD integration
Building distributed systems with TCP, Redis, RabbitMQ, and event-driven patterns
Docker, Kubernetes, CI/CD, monitoring, logging, and production optimization
CQRS, Event Sourcing, GraphQL, WebSockets, and real-world architectural patterns
## NestJS vs Other Node.js Frameworks
Before committing to NestJS, understand how it compares to alternatives. This is the decision framework you should use when choosing a backend framework for a new project.
| Criteria | NestJS | Express | Fastify | Koa | Hono |
| ------------------ | ------------------------------ | ----------------------------- | -------------------------- | ------------------------- | --------------------- |
| **Architecture** | Opinionated, modular | Minimal, unopinionated | Minimal, plugin-based | Minimal, middleware-based | Minimal, edge-focused |
| **TypeScript** | First-class, built-in | Requires manual setup | Good support, manual setup | Requires manual setup | First-class |
| **DI System** | Built-in, powerful | None (bring your own) | None | None | None |
| **Learning Curve** | Steep (2-4 weeks) | Low (1-3 days) | Low (1-3 days) | Low (1-3 days) | Low (1-2 days) |
| **Team Scaling** | Excellent (enforced structure) | Poor (no conventions) | Fair | Poor | Fair |
| **Performance** | Good (Express/Fastify) | Good | Excellent | Good | Excellent |
| **Ecosystem** | Rich (official packages) | Massive (middleware) | Growing | Moderate | Growing |
| **Microservices** | Built-in support | Manual setup | Manual setup | Manual setup | Not designed for this |
| **Best For** | Enterprise APIs, large teams | Quick prototypes, simple APIs | High-throughput APIs | Lightweight APIs | Edge/serverless |
**Decision Framework -- When to Choose NestJS:**
* Your team has 3+ backend developers and you need enforced conventions
* You are building an API with authentication, database integration, background jobs, and microservices
* You want built-in testing utilities, DI, and modular architecture out of the box
* Your project will be maintained for 2+ years and will be handed off between teams
**When to Choose Something Else:**
* Solo developer building a simple CRUD API (Express or Hono is faster to start)
* Serverless functions or edge workers (Hono or plain Fastify)
* Your team is allergic to decorators and Angular-style patterns (Fastify with TypeBox)
* You need absolute maximum throughput and every millisecond matters (Fastify standalone)
## Learning Path
**Recommended Learning Order**: Follow the chapters sequentially. Each chapter builds on concepts from previous ones. Complete the hands-on exercises in each chapter before moving forward. If you already have NestJS experience, skip to whichever chapter covers your weakest area -- but revisit Dependency Injection (Chapter 2) regardless, since most intermediate-level NestJS bugs trace back to a misunderstanding of how DI works.
### Beginner Path (Weeks 1-4)
* Fundamentals → Dependency Injection → Controllers & Routing → Providers & Services
### Intermediate Path (Weeks 5-7)
* Database Integration → Authentication & Authorization → Testing
### Advanced Path (Weeks 8-12)
* Microservices → Deployment & Production → Advanced Patterns
## Real-World Projects
Throughout this course, you'll build:
1. **E-Commerce API** - Complete REST API with authentication, product management, and order processing
2. **Social Media Backend** - Real-time features with WebSockets, GraphQL, and microservices
3. **Task Management System** - CQRS implementation with event sourcing and advanced patterns
## Tools & Technologies
You'll work with:
* **NestJS** - Core framework
* **TypeScript** - Type-safe development
* **TypeORM & Prisma** - Database ORMs
* **JWT & Passport** - Authentication
* **Docker & Kubernetes** - Containerization and orchestration
* **Jest** - Testing framework
* **RabbitMQ & Redis** - Message brokers
* **GraphQL** - Query language
* **WebSockets** - Real-time communication
## Cross-Chapter Connection Map
Understanding how chapters relate to each other helps you build a complete mental model. Here is how the key concepts flow across the course:
```text theme={null}
Fundamentals (Ch 1)
|-- Modules, Controllers, Services (core building blocks)
|
v
Dependency Injection (Ch 2) Controllers & Routing (Ch 3)
|-- Provider scopes |-- Middleware, Guards, Interceptors, Pipes
|-- Custom providers |-- Request lifecycle (memorize this)
| |
v v
Providers & Services (Ch 4) Auth & Authorization (Ch 6)
|-- Repository pattern |-- JWT guards (uses Ch 3 guards)
|-- Domain-driven design |-- RBAC (uses Ch 3 Reflector + metadata)
| |
v v
Database Integration (Ch 5) Testing (Ch 7)
|-- TypeORM / Prisma |-- Mocking DI (uses Ch 2)
|-- Migrations, Transactions |-- Override guards (uses Ch 3)
| |
v v
Microservices (Ch 8) Deployment (Ch 9)
|-- Message patterns |-- Docker, K8s, CI/CD
|-- Event-driven design |-- Health checks (uses Ch 9.4)
| |
+-----------+---------------------------+
|
v
Advanced Patterns (Ch 10)
|-- CQRS (uses Ch 2 DI + Ch 4 services)
|-- GraphQL (alternative to Ch 3 REST controllers)
|-- WebSockets (real-time, uses Ch 6 auth)
|-- Event Sourcing (uses Ch 8 event patterns)
```
## Getting Started
Ready to begin? Start with [Chapter 1: Fundamentals](/courses/nestjs/fundamentals) to set up your development environment and build your first NestJS application.
This course assumes familiarity with JavaScript/TypeScript and basic Node.js concepts. If you're new to TypeScript, we recommend reviewing TypeScript basics before starting. Specifically, you should be comfortable with interfaces, generics, and decorators -- these three features underpin nearly everything NestJS does under the hood.
## Interview Deep-Dive
**Strong Answer:**
* The decision hinges on team size, project lifespan, and complexity. For a solo developer building a simple CRUD API that ships in two weeks, Express or Fastify is faster to start with -- NestJS's module system and DI overhead is not worth it for 5 endpoints.
* NestJS pays for itself when you have 3+ backend developers, because it enforces conventions (modules, DI, decorators) that prevent the "every developer builds their own Express app" problem. I have seen Express codebases with 10 developers where each person organized their code differently -- middleware in different folders, inconsistent error handling, no DI. Refactoring that is a months-long effort.
* The real cost of NestJS is the learning curve (2-4 weeks for a developer unfamiliar with decorator-based frameworks) and the abstraction overhead. If you need absolute maximum throughput and every millisecond counts, Fastify standalone benchmarks 15-20% faster than NestJS with the Fastify adapter, because NestJS adds its own middleware pipeline on top.
* In practice, at companies like Adidas (who use NestJS in production), the framework's built-in testing utilities, DI system, and module architecture saved more engineering time than the performance difference cost. For most business APIs, the bottleneck is database queries, not framework overhead.
* My decision framework: if the project will be maintained for 2+ years, has authentication, database integration, background jobs, and multiple developers -- NestJS. If it is a serverless function, a quick prototype, or a performance-critical proxy layer -- Express or Fastify.
**Follow-up: You mentioned NestJS can use Fastify as the underlying HTTP engine. When would you swap Express for Fastify under NestJS, and what breaks?**
When throughput matters and you are handling 5,000+ requests per second, switching to the Fastify adapter (`@nestjs/platform-fastify`) gives you 20-30% better raw throughput because Fastify uses a radix tree for routing and avoids the middleware chain overhead of Express. The swap is a one-line change in `main.ts` (`NestFactory.create(AppModule, new FastifyAdapter())`).
What breaks: any Express-specific middleware (like `express-session`, `multer` for file uploads, or `passport` strategies that depend on Express's `req`/`res` signature). You need to find Fastify equivalents (`@fastify/multipart`, `@fastify/session`). Also, if your team has custom middleware that calls `res.json()` directly, it will not work because Fastify's response API is different. In my experience, the migration is straightforward for new projects but painful for existing ones with deep Express middleware dependencies.
**Strong Answer:**
* The lifecycle is: Middleware, Guards, Interceptors (before), Pipes, Controller Handler, Service, Interceptors (after), Exception Filters, Response. This order is not arbitrary -- it is designed so that each layer can short-circuit the pipeline appropriately.
* Middleware runs first because it handles low-level concerns like body parsing, CORS, and request logging -- things that apply to every request regardless of route. Guards run next because there is no point validating or transforming data if the user is not authorized. Pipes run after guards to validate and transform the request payload before it reaches the controller.
* In production, knowing this order is critical for debugging. I once spent hours debugging why a validation error was not being caught by our custom exception filter, only to realize the error was thrown in middleware (before the NestJS pipeline), so exception filters never saw it. Middleware errors need their own try/catch because they run outside the NestJS exception filter scope.
* Another common production issue: interceptors wrap the handler in an RxJS observable pipeline. If your interceptor has a `timeout(5000)` operator and your service takes 6 seconds, the timeout fires, but the service call is not canceled -- it keeps running in the background, potentially writing to the database even though the client got a timeout error. You need to handle cancellation explicitly.
**Follow-up: If you have a global guard, a controller-level guard, and a method-level guard, what is the execution order, and what happens if the global guard rejects?**
Global guards run first, then controller-level, then method-level. If the global guard returns `false` or throws, the request is rejected immediately -- the controller-level and method-level guards never execute, the pipe never validates, and the controller handler never runs. NestJS automatically responds with a 403 Forbidden (or whatever exception the guard throws). This is why authentication should be a global guard and authorization (like roles) should be method-level -- you want to verify identity universally before checking specific permissions.
**Strong Answer:**
* Technically, you can -- Express middleware can do authentication, validation, and logging. The problem is that Express middleware only has access to `req`, `res`, and `next()`. It does not know which controller method will handle the request, what metadata (like `@Roles('admin')`) is attached to that method, or what the handler's return value is.
* Guards solve the "should this request proceed" question and can read route metadata via the Reflector. You cannot build a role-based guard in Express middleware without manually mapping routes to roles -- NestJS guards read `@SetMetadata('roles', ['admin'])` from the handler automatically.
* Interceptors wrap the handler and can see the response data via RxJS, enabling response transformation, caching, and timing. Express middleware cannot access the handler's return value -- once you call `next()`, you lose control of the response unless you monkey-patch `res.json`.
* Pipes validate and transform individual parameters (like `@Param('id', ParseIntPipe)`). Express middleware would have to manually parse and validate each parameter, and the validation logic would be coupled to the route path.
* The practical rule: use middleware for cross-cutting concerns that do not need NestJS context (logging, CORS, compression). Use guards for auth, interceptors for response transformation and timing, and pipes for input validation. This separation makes each concern testable in isolation.
**Follow-up: Can a NestJS interceptor replace an exception filter? When would you use one over the other?**
An interceptor can catch errors using `catchError` in the RxJS pipe, so technically it can handle exceptions. But exception filters are more appropriate for error handling because they receive the full exception object and the `ArgumentsHost`, letting you format error responses based on the transport layer (HTTP, WebSocket, gRPC). Interceptors are better for transforming successful responses. In practice, I use interceptors for `catchError` only when I want to convert one exception type to another (like converting a database constraint violation into a ConflictException). For formatting error responses consistently, I use a global exception filter.
**Strong Answer:**
* I would use the NestJS monorepo mode (`nest generate app` and `nest generate library`) rather than a multi-repo setup. The monorepo gives you atomic commits across services, shared TypeScript configuration, and a single CI pipeline. For 8 developers, this reduces the "my service works but yours does not" problem significantly.
* The structure would separate apps (API gateway, order service, inventory service, notification service) from libraries (shared DTOs, common decorators, database utilities, auth library). Libraries live in `libs/` and are imported as `@app/shared-dto`, `@app/auth`, etc.
* Shared DTOs are critical -- when the order service publishes an `order_created` event and the notification service consumes it, both must agree on the payload shape. Putting the DTO in a shared library means a change to the event shape breaks the build for both services immediately, instead of causing a runtime error in production.
* For team ownership, I would assign modules, not files. Team A owns `OrdersModule` and `PaymentsModule`, Team B owns `InventoryModule` and `ShippingModule`. Each module has its own directory, its own tests, and its own CODEOWNERS entry. Cross-module dependencies go through exported interfaces, not direct imports of internal services.
* The common pitfall with monorepos is build time. With 8 developers committing frequently, rebuilding everything on every commit slows CI. Use `nx` or NestJS's built-in project references to enable incremental builds -- only rebuild what changed.
**Follow-up: How would you handle database migrations in this monorepo if each service has its own database?**
Each service gets its own Prisma schema (or TypeORM configuration) pointing to its own database. Migrations live alongside the service in `apps/order-service/prisma/migrations/`. The CI pipeline runs migrations per-service, in dependency order -- the user service migrates before the order service if orders reference users via an API call (not a foreign key, since they are separate databases). I have seen teams try to share a single database across services "for simplicity" and it always ends in tears -- a migration in the order service locks a table that the inventory service is reading, causing cascading timeouts. Separate databases from day one.