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

Question

IT Interview Practice · 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.

Por qué es importante

El orden completo del ciclo de vida de la solicitud

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

Cuándo usar middleware vs guards vs interceptors

Por qué es importante

Preguntas relacionadas