NestJS Middleware

Middleware runs before a request reaches a route handler, exactly as in Express. This lesson covers writing NestJS middleware as functions or classes, and applying it to specific routes.

What Is NestJS Middleware?

NestJS middleware is essentially Express (or Fastify) middleware, a function with access to the request, response, and a next() function, executed before guards, interceptors, pipes, and the route handler itself.

Nest supports two styles: simple functional middleware, and class-based middleware implementing the NestMiddleware interface, which can use dependency injection.

import { Injectable, NestMiddleware } from '@nestjs/common';
import { Request, Response, NextFunction } from 'express';

@Injectable()
export class LoggerMiddleware implements NestMiddleware {
  use(req: Request, res: Response, next: NextFunction) {
    console.log(`${req.method} ${req.originalUrl}`);
    next();
  }
}

Class-based middleware implements a single use() method with the exact same signature as an Express middleware function, but can inject other providers through its constructor.

Applying Middleware in a Module

export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer) {
    consumer
      .apply(LoggerMiddleware)
      .forRoutes('cats');
  }
}

Middleware is registered in a module's configure() method, not in @Module() metadata.
forRoutes() accepts a path string, a controller class, or an object with a path and method.
exclude() can skip specific routes within an otherwise-matched path.
Global middleware is registered directly on the app instance with app.use() in main.ts.

Middleware Cheatsheet

The essentials for writing and applying NestJS middleware.

Concept	Example
Functional middleware	`function logger(req, res, next) { next(); }`
Class middleware	`class LoggerMiddleware implements NestMiddleware`
Apply to routes	`consumer.apply(LoggerMiddleware).forRoutes('cats')`
Apply globally	`app.use(logger)` in `main.ts`
Exclude routes	`.exclude('cats/(.*)').forRoutes(CatsController)`

Functional vs. Class-Based Middleware

Functional middleware is a plain function and cannot use dependency injection, it's best for simple, stateless logic like request logging. Class-based middleware can inject other providers (like a ConfigService), making it the better choice whenever middleware needs access to application services.

Where Middleware Fits in the Request Pipeline

Middleware runs earliest in the pipeline, before guards, interceptors, and pipes. This makes it well suited for cross-cutting concerns that apply broadly (logging, request ID tagging, raw body capture), while guards and pipes are better suited for concerns tied specifically to a given route's authorization or input shape.

Common Mistakes

Forgetting to call next(), which stalls the request indefinitely.
Reaching for middleware when a guard or interceptor would fit the concern better (e.g. authorization logic belongs in a guard, not middleware).
Registering middleware in @Module() metadata instead of the configure() method.
Using functional middleware when the logic actually needs an injected provider.

Key Takeaways

NestJS middleware follows the exact same signature as Express middleware.
Class-based middleware implements NestMiddleware and supports dependency injection.
Middleware is registered via a module's configure() method with MiddlewareConsumer.
Middleware runs before guards, interceptors, and pipes in the request pipeline.

Pro Tip

Reserve middleware for concerns that genuinely don't belong to a specific route's business logic, request logging, correlation IDs, raw body capture for webhooks. Authorization and input validation almost always belong in a guard or pipe instead, where they're easier to test in isolation.