Mikä on NestJS:n request lifecycle -järjestys?

Question

Accepted Answer

**Request Lifecycle** on tarkka komponenttisarja, jonka kautta pyyntö kulkee NestJS:ssa — middleware, guards, interceptorit, pipes, handler, sitten interceptorit uudelleen, ja exception filters virheissä. Tarkan järjestyksen tunteminen on kriittistä ymmärtääksesi *milloin* jokainen logiikan osa suoritetaan.

## Täydellinen järjestys

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

## Miksi järjestys on tärkeä (käytännölliset seuraukset)

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

## Jokaisen kategorian sisällä sovelletaan 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.
```

## Konkreettinen esimerkki

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

## Miksi se on tärkeä

Request lifecycle -järjestyksen ymmärtäminen on perustavaa NestJS-sovellusten oikealle rakentamiselle — se määrittelee tarkasti *milloin* jokainen cross-cutting-logiikan osa suoritetaan, mikä vaikuttaa suoraan suunnittelupäätöksiin ja virheenetsintään.

Järjestyksellä on todellinen, käytännöllinen merkitys: **guardid suoritetaan ennen pipeja**, joten valtuutus tarkistetaan oikein ennen kuin vaivautumme syötteen validointiin (valtuuttamaton pyyntö hylätään ennen validointia); **piped suoritetaan juuri ennen handleria**, mikä takaa, että handler saa aina validoidut, muutetut argumentit; **interceptorit käärivät handlerin** (suoritetaan ennen *ja* jälkeen), mikä on juuri sitä, mikä sallii niiden ajoittaa suoritus ja muuntaa vastaukset; ja **exception filtterit ottavat vastaan virheet mistä tahansa vaiheesta**, mikä mahdollistaa keskitetyn virheenkäsittelyn.

Tämän järjestyksen tunteminen — sekä scope ordering kategorioiden sisällä (global → controller → method) — antaa sinulle mahdollisuuden sijoittaa logiikka oikeaan komponenttiin, ennustaa suoritusvirta, virheenjäljitys miksi jokin suoritetaan (tai ei) kun odotetaan, ja rakentaa ominaisuuksia oikein.

Se yhdistää kaikki kehyksen pyynnönkäsittelyn osat (middleware, guardid, interceptorit, piped, filtterit) johdonmukaiseksi henkiseksi malliksi, mikä tekee siitä tärkeän, usein testatun aiheen, joka heijastaa todellista ymmärrystä siitä, kuinka NestJS käsittelee pyyntöjä.