Wat is de NestJS request lifecycle order?

Question

Accepted Answer

De **request lifecycle** is de precieze reeks componenten waardoor een request in NestJS gaat — middleware, guards, interceptors, pipes, de handler, vervolgens interceptors opnieuw, en exception filters bij fouten. Het kennen van de exacte volgorde is cruciaal om te begrijpen *wanneer* elk stuk logica wordt uitgevoerd.

## De volledige volgorde

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

## Waarom de volgorde belangrijk is (praktische gevolgen)

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

## Binnen elke categorie geldt scope ordering

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

## Een concreet voorbeeld

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

## Waarom het belangrijk is

De request lifecycle order begrijpen is fundamenteel voor het correct bouwen van NestJS applicaties — het bepaalt precies *wanneer* elk stuk cross-cutting logica wordt uitgevoerd, wat rechtstreeks van invloed is op ontwerpbeslissingen en debugging.

De volgorde heeft echte, praktische betekenis: **guards worden vóór pipes uitgevoerd**, dus autorisatie wordt correct gecontroleerd voordat we moeite doen input te valideren (een ongeautoriseerde request wordt afgewezen voordat validatie plaatsvindt); **pipes worden net vóór de handler uitgevoerd**, waardoor de handler altijd gevalideerde, getransformeerde argumenten ontvangt; **interceptors wrappen de handler** (ze worden vóór *en* na uitgevoerd), wat precies wat hen in staat stelt uitvoering in te plannen en responses te transformeren; en **exception filters vangen fouten uit elke fase**, wat gecentraliseerde foutafhandeling mogelijk maakt.

Deze volgorde kennen — plus de within-category scope ordering (global → controller → method) — stelt je in staat logica in het juiste component te plaatsen, executieflow te voorspellen, op te debuggen waarom iets wel (of niet) wordt uitgevoerd op het moment dat je het verwacht, en functies correct te ontwerpen.

Het verbindt alle request-handling pieces van het framework (middleware, guards, interceptors, pipes, filters) in een samenhangend mentaal model, wat het een belangrijk, frequently-tested onderwerp maakt dat echte begrip van hoe NestJS requests verwerkt weerspiegelt.