Applying middleware to routes in NestJS - Deep Dive

Overview - Applying middleware to routes

What is it?

Applying middleware to routes means adding special functions that run before your route handlers in a NestJS application. These functions can modify requests, responses, or perform checks like authentication. Middleware acts like a checkpoint that every request passes through before reaching the final code that sends a response. It helps organize common tasks that many routes might share.

Why it matters

Without middleware, you would have to repeat the same code in every route handler, making your app messy and hard to maintain. Middleware lets you write code once and apply it to many routes, saving time and reducing mistakes. It also helps keep your app secure and efficient by handling things like logging, authentication, or data parsing in one place.

Where it fits

Before learning middleware, you should understand basic NestJS routing and controllers. After mastering middleware, you can explore advanced topics like guards, interceptors, and exception filters to control request flow and responses more deeply.

Mental Model

Core Idea

Middleware is a function that sits between the incoming request and the route handler, processing or modifying the request before it reaches the final code.

Think of it like...

Middleware is like a security checkpoint at an airport where every passenger (request) must pass through before boarding the plane (route handler). The checkpoint can check tickets, scan bags, or give instructions, ensuring only the right passengers proceed smoothly.

Incoming Request
     ↓
┌───────────────┐
│   Middleware  │  ← runs first, can modify request or response
└───────────────┘
     ↓
┌───────────────┐
│ Route Handler │  ← final code that sends response
└───────────────┘
     ↓
Outgoing Response

Build-Up - 6 Steps

1

Foundation

What is Middleware in NestJS

Concept: Middleware are functions that execute during the request-response cycle before the route handler.

In NestJS, middleware functions receive the request and response objects and a next function to pass control. They can read or change the request, perform tasks like logging, or block requests if needed. Middleware is registered to run on specific routes or globally.

Result

You understand that middleware acts as a pre-step before your route code runs, allowing you to add common logic in one place.

Understanding middleware as a pre-route step helps you organize code that applies to many routes without repeating yourself.

2

Foundation

Creating a Simple Middleware Function

Concept: How to write a basic middleware function in NestJS using the MiddlewareConsumer interface.

Create a class implementing NestMiddleware with a use() method. This method receives request, response, and next. Inside use(), you can log request info or modify request properties. Call next() to continue to the next middleware or route handler.

Result

You can create middleware that logs every request URL before the route handles it.

Knowing how to write middleware functions is the first step to applying shared logic across routes.

3

Intermediate

Applying Middleware to Specific Routes

🤔Before reading on: Do you think middleware can be applied only globally or also to specific routes? Commit to your answer.

Concept: NestJS allows applying middleware to specific routes or route patterns using MiddlewareConsumer in modules.

In your module's configure() method, use MiddlewareConsumer to apply middleware with apply(). You can chain forRoutes() to specify which routes or controllers the middleware should affect. This lets you target middleware only where needed.

Result

Middleware runs only on the routes you specify, not on every request.

Knowing how to target middleware prevents unnecessary processing and keeps your app efficient.

4

Intermediate

Using Middleware with Route Parameters and Wildcards

🤔Before reading on: Can middleware be applied to routes with parameters or wildcards? Guess yes or no.

Concept: Middleware can be applied to routes with dynamic parameters or wildcard patterns to cover multiple routes at once.

In forRoutes(), you can specify routes like 'users/:id' or use wildcards like 'admin/*' to apply middleware broadly. This helps when many routes share similar needs, like authentication on all admin pages.

Result

Middleware runs on all matching routes, including those with parameters or wildcards.

Understanding route pattern matching in middleware lets you cover many routes with one middleware efficiently.

5

Advanced

Global Middleware vs Route-specific Middleware

🤔Before reading on: Which do you think runs first, global or route-specific middleware? Commit to your answer.

Concept: Global middleware runs on every request, while route-specific middleware runs only on chosen routes. Their order affects request processing.

Global middleware is applied in main.ts using app.use(). Route-specific middleware is configured in modules. Global middleware runs before route-specific middleware. This order matters for tasks like logging or authentication.

Result

You can control middleware execution order and scope for better app behavior.

Knowing middleware order helps avoid conflicts and ensures security checks happen at the right time.

6

Expert

Middleware Execution Flow and NestJS Internals

🤔Before reading on: Do you think NestJS middleware runs inside the same context as controllers or separately? Guess before reading.

Concept: Middleware runs outside NestJS's dependency injection and request lifecycle, affecting how you access services inside middleware.

NestJS middleware functions run before the framework creates controller instances. This means you cannot inject services directly into middleware classes unless using functional middleware or wrappers. To access services, you might use functional middleware or global interceptors instead.

Result

You understand middleware limitations and how to work around them for complex logic.

Knowing middleware runs outside NestJS's DI system prevents confusion and guides you to use the right tool for your needs.

Under the Hood

When a request arrives, NestJS passes it through any global middleware first, then through route-specific middleware configured in modules. Middleware functions receive the raw request and response objects and a next callback. Calling next() passes control to the next middleware or the route handler. Middleware runs outside NestJS's dependency injection system, so it cannot directly use injected services unless special patterns are used.

Why designed this way?

Middleware follows the Express.js pattern for compatibility and simplicity. Running middleware outside the DI system keeps it lightweight and fast, suitable for generic tasks like logging or parsing. More complex logic requiring DI is handled by guards or interceptors, which integrate tightly with NestJS's lifecycle.

Incoming Request
     ↓
┌─────────────────────┐
│ Global Middleware    │  (runs first, outside DI)
└─────────────────────┘
     ↓
┌─────────────────────┐
│ Module Middleware    │  (route-specific, outside DI)
└─────────────────────┘
     ↓
┌─────────────────────┐
│ Controller Handler   │  (inside DI, handles request)
└─────────────────────┘
     ↓
Outgoing Response

Myth Busters - 4 Common Misconceptions

Quick: Does middleware have access to NestJS dependency injection services by default? Commit yes or no.

Common Belief: Middleware can inject and use any NestJS service like controllers or providers.

Reality: Middleware runs outside NestJS's dependency injection system and cannot inject services directly unless using special functional middleware patterns.

Why it matters: Trying to inject services in middleware without knowing this causes runtime errors and confusion.

Quick: Is middleware the same as guards or interceptors in NestJS? Commit yes or no.

Common Belief: Middleware, guards, and interceptors are interchangeable and do the same thing.

Reality: Middleware runs before route handlers and can modify requests/responses, guards control access based on authorization, and interceptors transform responses or handle extra logic after handlers.

Why it matters: Confusing these leads to misuse and harder-to-maintain code.

Quick: Does applying middleware globally mean it runs on every request including static assets? Commit yes or no.

Common Belief: Global middleware only runs on API routes, not on static files or assets.

Reality: Global middleware runs on every request, including static assets, unless explicitly excluded.

Why it matters: Unintended middleware on static assets can slow down your app or cause errors.

Quick: Can middleware stop a request from reaching the route handler? Commit yes or no.

Common Belief: Middleware must always call next() to continue the request.

Reality: Middleware can choose not to call next(), effectively ending the request early, for example, to block unauthorized access.

Why it matters: Understanding this helps implement security checks and error handling properly.

Expert Zone

1

Middleware runs outside NestJS's dependency injection, so accessing services requires workarounds like functional middleware or global interceptors.

2

The order of middleware matters: global middleware runs before route-specific middleware, affecting how requests are processed and logged.

3

Middleware can modify the request and response objects directly, but changes must be done carefully to avoid side effects or breaking the request flow.

When NOT to use

Middleware is not suitable for tasks requiring dependency injection or complex request lifecycle control; use guards for authorization, interceptors for response transformation, and exception filters for error handling instead.

Production Patterns

In production, middleware is commonly used for logging, request parsing (like JSON body parsing), authentication checks on route groups, and rate limiting. Developers often combine global middleware for app-wide concerns and route-specific middleware for targeted features.

Connections

Express.js Middleware

NestJS middleware builds on Express.js middleware patterns for compatibility and familiarity.

Understanding Express middleware helps grasp NestJS middleware behavior since NestJS uses Express under the hood by default.

Software Design Patterns - Chain of Responsibility

Middleware implements the Chain of Responsibility pattern, passing requests through a chain of handlers.

Recognizing this pattern clarifies how middleware can modify or stop requests in a flexible, decoupled way.

Airport Security Checkpoints

Middleware functions like security checkpoints that inspect and control access before final processing.

This analogy helps understand middleware's role in filtering and preparing requests before they reach their destination.

Common Pitfalls

#1 Trying to inject services directly into middleware classes.

Wrong approach:

export class LoggerMiddleware implements NestMiddleware {
constructor(private readonly service: SomeService) {}
use(req: Request, res: Response, next: Function) {
this.service.log(req.url);
next();
}
}

Correct approach:

export class LoggerMiddleware implements NestMiddleware {
use(req: Request, res: Response, next: Function) {
console.log(req.url);
next();
}
}

Root cause:

Middleware runs outside NestJS's dependency injection system, so injected services are undefined.

#2 Not calling next() in middleware, causing requests to hang.

Wrong approach:

export class AuthMiddleware implements NestMiddleware {
use(req: Request, res: Response, next: Function) {
if (!req.headers.authorization) {
res.status(401).send('Unauthorized');
}
// missing next() call
}
}

Correct approach:

export class AuthMiddleware implements NestMiddleware {
use(req: Request, res: Response, next: Function) {
if (!req.headers.authorization) {
return res.status(401).send('Unauthorized');
}
next();
}
}

Root cause:

Forgetting to call next() or return after sending a response blocks the request pipeline.

#3 Applying middleware globally without excluding static assets.

Wrong approach:

app.use(LoggerMiddleware); // runs on all requests including static files

Correct approach:

app.use('/api', LoggerMiddleware); // runs only on API routes

Root cause:

Not scoping middleware causes unnecessary processing and possible errors on static asset requests.

Key Takeaways

Middleware in NestJS runs before route handlers to process requests and responses, helping share common logic.

Middleware functions run outside NestJS's dependency injection system, limiting direct access to services.

You can apply middleware globally or to specific routes, including routes with parameters or wildcards.

Middleware order matters: global middleware runs before route-specific middleware, affecting request flow.

Understanding middleware's role and limits helps you choose the right tool for tasks like logging, authentication, or request modification.