Vad är livscykelordningen för NestJS-begäranden?

Question

Accepted Answer

**Livscykeln för begäranden** är den exakta sekvensen av komponenter som en begäran passerar genom i NestJS — middleware, guards, interceptors, pipes, hanteraren, sedan interceptors igen, och exception filters vid fel. Att känna till den exakta ordningen är avgörande för att förstå *när* varje logikbit körs.

## Hela ordningen

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

## Varför ordningen är viktig (praktiska 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
```

## Inom varje kategori gäller scope-ordningen

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

## Ett konkret exempel

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

## Varför det spelar roll

Att förstå livscykelordningen för begäranden är grundläggande för att bygga NestJS-applikationer korrekt — det avgör exakt *när* varje del av korsande logik körs, vilket direkt påverkar designbeslut och felsökning.

Ordningen har verklig, praktisk betydelse: **guards körs före pipes**, så auktorisering kontrolleras korrekt innan vi ens försöker validera inmatning (en obehörig begäran avvisas före validering); **pipes körs precis före hanteraren**, vilket garanterar att hanteraren alltid mottar validerade, transformerade argument; **interceptors omsluter hanteraren** (körs före *och* efter), vilket är exakt det som låter dem mäta körning och transformera svar; och **exception filters fångar fel från vilken fas som helst**, vilket möjliggör centraliserad felhantering.

Att känna till denna ordning — plus scope-ordningen inom varje kategori (global → controller → metod) — låter dig placera logik i rätt komponent, förutsäga exekveringsflödet, felsöka varför något körs (eller inte körs) när förväntat, och arkitekturera funktioner korrekt.

Det förenar alla ramverkets begärandehanteringsdelar (middleware, guards, interceptors, pipes, filters) till en koherent mentalmodell, vilket gör det till ett viktigt, ofta testat ämne som återspeglar genuin förståelse för hur NestJS bearbetar begäranden.