Care este ordinea ciclului de viață al cererii în NestJS?

Question

Accepted Answer

**Ciclul de viață al cererii** este secvența precisă de componente prin care trece o cerere în NestJS — middleware, guards, interceptors, pipes, handler, apoi din nou interceptors și exception filters în caz de erori. Cunoașterea ordinii exacte este crucială pentru a înțelege *când* se execută fiecare bucată de logică.

## Ordinea completă

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

## De ce ordinea are importanță (consecințe practice)

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

## În cadrul fiecărei categorii, ordinea domeniului se aplică

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

## Un exemplu concret

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

## De ce conteaza

Înțelegerea ordinii ciclului de viață al cererii este fundamentală pentru construirea corectă a aplicațiilor NestJS — determină exact *când* se execută fiecare bucată de logică transversală, ceea ce afectează direct deciziile de proiectare și depanarea.

Ordinea are o semnificație reală și practică: **guards se execută înainte de pipes**, deci autorizarea este verificată corect înainte de a deranja cu validarea intrării (o cerere neautorizată este respingă înainte de validare); **pipes se execută chiar înainte de handler**, garantând că handler primește întotdeauna argumente validate și transformate; **interceptors înfășoară handler** (execundu-se înainte *și* după), ceea ce este exact ceea ce le permite să cronometreze execuția și să transforme răspunsurile; și **exception filters prind erori din orice etapă**, permițând tratarea centralizată a erorilor.

Cunoașterea acestei ordini — plus ordinea domeniului în cadrul categoriei (global → controller → method) — vă permite să plasați logica în componenta corectă, să preveniți fluxul de execuție, să depanați de ce ceva se execută (sau nu se execută) când se așteaptă, și să arhitectați caracteristicile corect.

Este leagă laolaltă toate componentele de tratare a cererilor ale framework-ului (middleware, guards, interceptors, pipes, filters) într-un model mental coerent, făcând din acesta un subiect important și frecvent testat care reflectă o înțelegere genuină a modului în care NestJS procesează cererile.