Quel est l'ordre du cycle de vie des requêtes dans NestJS ?

Question

Accepted Answer

Le **cycle de vie de la requête** est la séquence précise des composants par lesquels passe une requête dans NestJS — middleware, guards, interceptors, pipes, le handler, puis à nouveau les interceptors, et les exception filters en cas d'erreur. Connaître l'ordre exact est crucial pour comprendre *quand* chaque morceau de logique s'exécute.

## The full order

```text
Incoming Request
   │
   ▼
1. MIDDLEWARE            (Express-style; raw req/res; runs first)
   │
   ▼
2. GUARDS                (authorization — return true to continue, false/throw to block)
   │
   ▼
3. INTERCEPTORS (pre)    (logic BEFORE the handler — start timing, etc.)
   │
   ▼
4. PIPES                 (validate/transform the handler's arguments — DTO validation)
   │
   ▼
5. ROUTE HANDLER         (your controller method runs)
   │
   ▼
6. INTERCEPTORS (post)   (logic AFTER the handler — transform the response)
   │
   ▼
Response

✗ If an exception is thrown ANYWHERE above →
7. EXCEPTION FILTERS     (catch it and format the error response)
```

## Why the order matters (practical consequences)

```text
• Guards run BEFORE pipes → authorization is checked before input validation
  (no point validating a body for an unauthorized request)
• Pipes run JUST BEFORE the handler → the handler always gets validated/transformed args
• Interceptors straddle the handler → they can measure its duration and transform output
• Filters catch errors from any stage → centralized, consistent error handling
```

## Within each category, scope ordering applies

```text
For each type (guards, interceptors, pipes), they run in this scope order:
  Global → Controller → Method (route)
So a global guard runs before a controller-level guard, before a route-level guard.
```

## A concrete example

```ts
@Controller("users")
@UseGuards(AuthGuard)                    // 2. checks authorization
@UseInterceptors(LoggingInterceptor)     // 3 (pre) + 6 (post)
export class UsersController {
  @Post()
  create(@Body() dto: CreateUserDto) {    // 4. ValidationPipe validates dto, 5. handler runs
    return this.usersService.create(dto);
  }
}
// Flow: middleware → AuthGuard → LoggingInterceptor(before) → ValidationPipe →
//       create() → LoggingInterceptor(after) → response (or → filter on error)
```

## Pourquoi c'est important

Comprendre l'ordre du cycle de vie des requêtes est fondamental pour construire correctement des applications NestJS — cela détermine exactement *quand* chaque morceau de logique transversale s'exécute, ce qui affecte directement les décisions de conception et le débogage.

L'ordre a une réelle signification pratique : **les guards s'exécutent avant les pipes**, donc l'autorisation est correctement vérifiée avant de se soucier de valider l'entrée (une requête non autorisée est rejetée avant la validation) ; **les pipes s'exécutent juste avant le handler**, garantissant que le handler reçoit toujours des arguments validés et transformés ; **les interceptors enveloppent le handler** (s'exécutant avant *et* après), ce qui est précisément ce qui leur permet de chronométrer l'exécution et de transformer les réponses ; et **les exception filters capturent les erreurs de n'importe quelle étape**, permettant une gestion centralisée des erreurs.

Connaître cet ordre — plus l'ordre d'étendue au sein de chaque catégorie (global → controller → method) — vous permet de placer la logique dans le bon composant, de prédire le flux d'exécution, de déboguer pourquoi quelque chose s'exécute (ou ne s'exécute pas) au moment attendu, et d'architecturer correctement les fonctionnalités.

Cela lie ensemble tous les éléments de traitement des requêtes du framework (middleware, guards, interceptors, pipes, filters) en un modèle mental cohérent, ce qui en fait un sujet important et fréquemment testé qui reflète une véritable compréhension de la façon dont NestJS traite les requêtes.