Hvad er rækkefølgen for request lifecycle i NestJS?

Question

IT Interview Practice · Accepted Answer

**Request Lifecycle** er den præcise sekvens af komponenter, som en request passerer gennem i NestJS — middleware, guards, interceptors, pipes, handler, derefter interceptors igen, og exception filters ved fejl. At kende den nøjagtige rækkefølge er afgørende for at forstå *hvornår* hver del af logikken kører.

## Den fulde rækkefølge

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

## Hvorfor rækkefølgen betyder noget (praktiske konsekvenser)

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

## Inden for hver kategori gælder 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.
```

## Et konkret eksempel

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

## Hvorfor det betyder noget

At forstå request lifecycle rækkefølgen er fundamental for at bygge NestJS-applikationer korrekt — det bestemmer præcist *hvornår* hver del af cross-cutting logik udføres, hvilket direkte påvirker designbeslutninger og fejlretning.

Rækkefølgen har virkelig praktisk betydning: **guards kører før pipes**, så autentificering kontrolleres korrekt før vi bekymrer os om at validere input (en uautoriseret request afvises før validering); **pipes kører lige før handleren**, hvilket garanterer at handleren altid modtager validerede, transformerede argumenter; **interceptors omgiver handleren** (køres før *og* efter), hvilket er præcis hvad der tillader dem at time udførelse og transformere svar; og **exception filters fanger fejl fra ethvert trin**, hvilket muliggør centraliseret fejlhåndtering.

At kende denne rækkefølge — plus scope ordering inden for kategorier (global → controller → method) — giver dig mulighed for at placere logik i den rigtige komponent, forudsige udførelsesflow, fejlretning af hvorfor noget kører (eller ikke kører) når forventet, og arkitekturere features korrekt.

Det sammenbinder alle frameworks request-handling stykker (middleware, guards, interceptors, pipes, filters) til en kohærent mentalt model, hvilket gør det til et vigtig, hyppigt testet emne der afspejler egentlig forståelse af hvordan NestJS behandler requests.

Den fulde rækkefølge

Hvorfor rækkefølgen betyder noget (praktiske konsekvenser)

Inden for hver kategori gælder scope ordering

Et konkret eksempel

Hvorfor det betyder noget

Relaterede spørgsmål