Hva er NestJS request lifecycle order?

Question

IT Interview Practice · Accepted Answer

**Request lifecycle** er den presise sekvensen av komponenter som en request passerer gjennom i NestJS — middleware, guards, interceptors, pipes, handler, deretter interceptors igjen, og exception filters ved feil. Å kjenne den eksakte rekkefølgen er avgjørende for å forstå *når* hver del av logikken kjører.

## Den fullstendige rekkefølgen

```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 rekkefølgen betyr noe (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
```

## Innenfor hver kategori gjelder 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 betyr noe

Å forstå request lifecycle order er grunnleggende for å bygge NestJS-applikasjoner riktig — det avgjør nøyaktig *når* hver del av tverrsnittlig logikk kjøres, noe som direkte påvirker designbeslutninger og debugging.

Rekkefølgen har reell, praktisk betydning: **guards kjøres før pipes**, så autorisasjon blir riktig sjekket før vi går i gang med å validere input (en uautorisert request blir avvist før validering); **pipes kjøres rett før handler**, noe som garanterer at handler alltid mottar validerte, transformerte argumenter; **interceptors wrapper handler** (kjøres før *og* etter), noe som er nøyaktig det som lar dem time kjøring og transformere svar; og **exception filters fanger opp feil fra ethvert stadium**, noe som muliggjør sentralisert feilhåndtering.

Å kjenne denne rekkefølgen — pluss scope ordering innenfor kategorier (global → controller → method) — lar deg plassere logikk i riktig komponent, forutsi kjøringsflyt, debugge hvorfor noe kjøres (eller ikke kjøres) når forventet, og arkitektur funksjoner korrekt.

Det knytter sammen alle framework sine request-handling biter (middleware, guards, interceptors, pipes, filters) til en sammenhengende mental modell, noe som gjør det til et viktig, ofte testet tema som gjenspeiler genuine forståelse av hvordan NestJS behandler requests.

Den fullstendige rekkefølgen

Hvorfor rekkefølgen betyr noe (praktiske konsekvenser)

Innenfor hver kategori gjelder scope ordering

Et konkret eksempel

Hvorfor det betyr noe

Relaterte spørsmål