Welche Reihenfolge hat der Request Lifecycle in NestJS?

Question

Accepted Answer

Der **Request Lifecycle** ist die genaue Abfolge von Komponenten, die ein Request in NestJS durchläuft — Middleware, Guards, Interceptors, Pipes, Handler, dann Interceptors erneut und Exception Filters bei Fehlern. Die genaue Reihenfolge zu kennen ist entscheidend, um zu verstehen, *wann* jedes Stück der Logik ausgeführt wird.

## Die vollständige Reihenfolge

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

## Warum die Reihenfolge wichtig ist (praktische Konsequenzen)

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

## Innerhalb jeder Kategorie gilt 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.
```

## Ein konkretes Beispiel

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

## Warum es wichtig ist

Das Verständnis der Request Lifecycle Reihenfolge ist fundamental für den richtigen Aufbau von NestJS-Anwendungen — es bestimmt genau, *wann* jedes Stück der Cross-Cutting-Logik ausgeführt wird, was sich direkt auf Designentscheidungen und Debugging auswirkt.

Die Reihenfolge hat echte praktische Bedeutung: **Guards laufen vor Pipes**, sodass die Autorisierung korrekt überprüft wird, bevor wir uns mit der Validierung von Eingaben befassen (ein nicht autorisierter Request wird vor der Validierung abgelehnt); **Pipes laufen unmittelbar vor dem Handler**, was garantiert, dass der Handler immer validierte, transformierte Argumente erhält; **Interceptors umhüllen den Handler** (laufen vor *und* nach), was ihnen ermöglicht, die Ausführung zu timen und Antworten zu transformieren; und **Exception Filters fangen Fehler von jeder Stufe**, was zentralisierte Fehlerbehandlung ermöglicht.

Dieses Wissen — plus Scope Ordering innerhalb von Kategorien (global → controller → method) — ermöglicht es dir, Logik in die richtige Komponente zu platzieren, den Ausführungsfluss vorherzusagen, zu debuggen, warum etwas läuft (oder nicht läuft), wenn erwartet, und Features korrekt zu architektieren.

Es verbindet alle Request-Handling-Stücke des Frameworks (Middleware, Guards, Interceptors, Pipes, Filters) zu einem kohärenten mentalen Modell, was es zu einem wichtigen, häufig getesteten Thema macht, das echtes Verständnis dafür widerspiegelt, wie NestJS Requests verarbeitet.