Qu'est-ce que le middleware dans NestJS et comment diffère-t-il des guards/interceptors ?

Question

Accepted Answer

**Middleware** est une fonction qui s'exécute **avant le gestionnaire de route**, avec accès aux objets request et response — le même concept que le middleware Express. NestJS a aussi des guards, des interceptors, des pipes et des filters, chacun s'exécutant à un point spécifique du cycle de vie de la requête avec un objectif distinct. Savoir lequel utiliser est essentiel.

## Middleware — s'exécute en premier, a 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
  }
}
```

Le middleware s'exécute en premier, avant les guards/interceptors/pipes, et travaille avec `req`/`res` bruts — idéal pour la journalisation, la modification de requête, CORS et les préoccupations compatibles avec Express.

## L'ordre complet du cycle de vie de la requête

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

## À quoi sert chacun (choisir le bon outil)

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

Les distinctions clés : le middleware est un pré-traitement générique de style Express ; **les guards** gèrent spécifiquement l'autorisation (un endroit dédié et propre pour l'auth, contrairement à le mettre dans le middleware) ; **les interceptors** enveloppent le gestionnaire pour transformer les réponses ou ajouter du comportement transversal ; **les pipes** valident l'entrée ; **les filters** gèrent les erreurs.

## Quand utiliser le middleware vs les guards vs les 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
```

## Pourquoi c'est important

Comprendre le middleware et comment il diffère des guards, interceptors, pipes et filters est essentiel pour structurer correctement les applications NestJS — chacun a un rôle spécifique et s'exécute à un point spécifique du cycle de vie de la requête, et utiliser le bon produit un code propre et idiomatique.

Le middleware gère le pré-traitement générique de style Express avec req/res bruts.

Les distinctions cruciales sont que **les guards** sont l'endroit dédié et approprié pour l'autorisation (auth/roles) — bien plus propre que le middleware à cet effet — et **les interceptors** enveloppent le gestionnaire pour transformer les réponses et ajouter des préoccupations transversales (journalisation, cache, timing) que le middleware ne peut pas facilement faire (puisqu'il s'exécute avant le gestionnaire et ne voit pas naturellement la réponse).

Connaître l'ordre complet du cycle de vie (middleware → guards → interceptors → pipes → gestionnaire → interceptors → filters) et quel outil convient à chaque préoccupation (auth → guard, transformation de réponse → interceptor, validation → pipe, erreurs → filter) est une marque de compétence NestJS et évite l'erreur courante d'utiliser le middleware pour tout.

C'est un sujet fréquemment testé et architecturalement important dans le framework.