What is middleware in NestJS and how does it differ from guards/interceptors?

Question

Accepted Answer

**Middleware** is a function that runs **before the route handler**, with access to the request and response objects — the same concept as Express middleware. NestJS also has guards, interceptors, pipes, and filters, each running at a specific point in the request lifecycle with a distinct purpose. Knowing which to use is key.

## Middleware — runs first, has req/res

```ts
@Injectable()
export class LoggerMiddleware implements NestMiddleware {
  use(req: Request, res: Response, next: NextFunction) {
    console.log(`${req.method} ${req.url}`);   // logging, modifying req
    next();                                      // MUST call next() to continue
  }
}

// register in a module
export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer) {
    consumer.apply(LoggerMiddleware).forRoutes("*");   // apply to routes
  }
}
```

Middleware runs earliest, before guards/interceptors/pipes, and works with raw `req`/`res` — good for logging, request modification, CORS, and Express-compatible concerns.

## The full request lifecycle order

```text
Request →
  1. Middleware     (req/res; runs first, Express-style)
  2. Guards         (return true/false → AUTHORIZE or block the request)
  3. Interceptors   (BEFORE the handler)
  4. Pipes          (validate/transform the handler's arguments)
  5. → Route Handler ←
  6. Interceptors   (AFTER the handler — transform the response)
  7. Exception Filters (if an error was thrown anywhere)
→ Response
```

## What each is FOR (choosing the right tool)

```text
Middleware  → general pre-processing with req/res (logging, CORS, raw request work)
Guards      → AUTHORIZATION — decide if a request may proceed (auth, roles)
              (return true = allow, false/throw = block)
Interceptors→ wrap the handler — transform request/response, add logging/caching/timing
              (can run logic BEFORE and AFTER the handler)
Pipes       → VALIDATE/TRANSFORM the handler's input arguments (DTO validation)
Filters     → catch and format EXCEPTIONS into responses
```

The key distinctions: middleware is generic Express-style pre-processing; **guards** specifically handle authorization (a clean, dedicated place for auth, unlike cramming it into middleware); **interceptors** wrap the handler to transform responses or add cross-cutting behavior; **pipes** validate input; **filters** handle errors.

## When to use middleware vs guards vs interceptors

```text
Auth check?           → Guard (dedicated, has execution context, returns boolean)
Logging requests?     → Middleware OR an interceptor (interceptor sees the response too)
Transform responses?  → Interceptor (runs after the handler)
Validate a DTO?       → Pipe
Modify raw req early?  → Middleware
```

## Why it matters

Understanding middleware and how it differs from guards, interceptors, pipes, and filters is essential for structuring NestJS applications correctly — each has a specific role and runs at a specific point in the request lifecycle, and using the right one leads to clean, idiomatic code.

Middleware handles general Express-style pre-processing with raw req/res.

The crucial distinctions are that **guards** are the dedicated, proper place for authorization (auth/roles) — far cleaner than middleware for that purpose — and **interceptors** wrap the handler to transform responses and add cross-cutting concerns (logging, caching, timing) that middleware can't easily do (since it runs before the handler and doesn't naturally see the response).

Knowing the full lifecycle order (middleware → guards → interceptors → pipes → handler → interceptors → filters) and which tool fits each concern (auth → guard, response transformation → interceptor, validation → pipe, errors → filter) is a hallmark of NestJS competence and prevents the common mistake of misusing middleware for everything.

This is a frequently-tested, architecturally-important topic in the framework.