¿Qué es middleware en NestJS y cómo difiere de guards/interceptors?

Question

Accepted Answer

**Middleware** es una función que se ejecuta **antes del manejador de ruta**, con acceso a los objetos request y response — el mismo concepto que middleware de Express. NestJS también tiene guards, interceptors, pipes y filters, cada uno ejecutándose en un punto específico del ciclo de vida de la solicitud con un propósito distinto. Saber cuál usar es clave.

## Por qué es importante

```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 se ejecuta primero, antes de guards/interceptors/pipes, y funciona con `req`/`res` raw — bueno para logging, modificación de solicitudes, CORS y preocupaciones compatibles con Express.

## El orden completo del ciclo de vida de la solicitud

```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
```

## Para qué sirve cada uno (elegir la herramienta correcta)

```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
```

Las distinciones clave: middleware es pre-procesamiento genérico de estilo Express; **guards** manejan específicamente autorización (un lugar limpio y dedicado para auth, a diferencia de insertarlo en middleware); **interceptors** envuelven el manejador para transformar respuestas o añadir comportamiento transversal; **pipes** validan entrada; **filters** manejan errores.

## Cuándo usar 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
```

## Por qué es importante

Comprender middleware y cómo difiere de guards, interceptors, pipes y filters es esencial para estructurar correctamente las aplicaciones NestJS — cada uno tiene un rol específico y se ejecuta en un punto específico del ciclo de vida de la solicitud, y usar el correcto lleva a código limpio e idiomático.

Middleware maneja pre-procesamiento genérico de estilo Express con req/res raw.

Las distinciones cruciales son que **guards** son el lugar dedicado y apropiado para autorización (auth/roles) — mucho más limpio que middleware para ese propósito — e **interceptors** envuelven el manejador para transformar respuestas y añadir preocupaciones transversales (logging, caching, timing) que middleware no puede hacer fácilmente (ya que se ejecuta antes del manejador y no ve naturalmente la respuesta).

Conocer el orden completo del ciclo de vida (middleware → guards → interceptors → pipes → handler → interceptors → filters) y cuál es la herramienta para cada preocupación (auth → guard, transformación de respuesta → interceptor, validación → pipe, errores → filter) es marca de competencia en NestJS y previene el error común de maluso de middleware para todo.

Este es un tema frecuentemente probado e arquitectónicamente importante en el framework.