Koks yra NestJS užklausos gyvenimo ciklo tvarka?

Question

Accepted Answer

**Užklausos gyvenimo ciklas** yra tikslus komponentų, per kuriuos eina užklausa NestJS — middleware, guard, interceptor, pipe, handler, paskui vėl interceptor, o klaidoms — exception filter — sekos. Žinoti tikslią tvarką yra svarbu norint suprasti, *kada* veikliai kiekviena logikos dalis.

## Visa tvarka

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

## Kodėl tvarka svarbi (praktinės pasekmes)

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

## Kiekvienos kategorijos viduje taikoma scope tvarka

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

## Konkretus pavyzdys

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

## Kodėl tai svarbu

Suprasti užklausos gyvenimo ciklo tvarką yra pagrindinė NestJS programų kūrimo sąlyga — ji nusako tiksliai, *kada* vykdoma kiekviena cross-cutting logika, kuri tiesiogiai veikia projektavimo sprendimus ir derinimą.

Tvarka turi realią, praktinę reikšmę: **guard'ai veikia prieš pipes**, todėl autorizacija tikrinama tinkamai prieš variklio patvirtinimą (neautorizuota užklausa atmesta prieš validaciją); **pipes veikia tiesiai prieš handler**, garantuodama, kad handler visada gauna patvirtintus ir transformuotus argumentus; **interceptors apvynioja handler** (veikdami prieš *ir* po), kas tiksliai leidžia jiems matuoti vykdymą ir transformuoti atsakymus; ir **exception filters nuslopina klaidas iš bet kurio etapo**, leidžiančios centralizuotą klaidų tvarkymą.

Žinant šią tvarką — plius scope tvarką kategorijose (globalinė → kontroleris → metodas) — galite padėti logiką tinkamame komponente, numatyti vykdymo srautą, atkurti, kodėl kažkas veikia (ar neveikia) kaip tikėtasi, ir teisingai architektūrinti funkcijas.

Tai sujungia visus framework'o užklausos tvarkymo gabalus (middleware, guard, interceptor, pipe, filter) į nuoseklų minčių modelį, todėl tai yra svarbi, dažnai testuojama tema, kuri atspindi tikrą supratimą apie tai, kaip NestJS apdoroja užklausas.