NestJS istek yaşam döngüsü (request lifecycle) sırası nedir?

Question

Accepted Answer

**İstek yaşam döngüsü**, bir isteğin NestJS'de geçtiği bileşenlerin kesin sırası — middleware, guard'lar, interceptor'lar, pipe'lar, handler, sonra tekrar interceptor'lar ve hatalarda exception filter'lar. Tam sırayı bilmek, *her bir mantığın ne zaman* çalıştığını anlamak için çok önemlidir.

## Tam sıra

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

## Neden önemli

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

## Her kategori içinde, kapsam sıralaması uygulanır

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

## Somut bir örnek

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

## Neden önemli

NestJS uygulamalarını doğru bir şekilde oluşturmak için istek yaşam döngüsü sırasını anlamak temel bir gereksinimdir — her bir cross-cutting mantığın tam olarak *ne zaman* yürütüleceğini belirler, bu da tasarım kararlarını ve hata ayıklamayı doğrudan etkiler.

Sıralanmanın gerçek, pratik bir anlamı vardır: **guard'lar pipe'lardan önce çalışır**, bu nedenle yetkilendirme girdileri doğrulamaktan önce doğru şekilde kontrol edilir (yetkisiz bir istek doğrulamadan önce reddedilir); **pipe'lar handler'dan hemen önce çalışır**, handler'ın her zaman doğrulanmış, dönüştürülmüş argümanlar almasını garantiler; **interceptor'lar handler'ı sarmaladığından** (öncesinde *ve* sonrasında çalışarak), yürütmeyi zamanlamayı ve yanıtları dönüştürmeyi sağlarlar; ve **exception filter'lar herhangi bir aşamadan hataları yakalar**, merkezi hata işlemeyi etkinleştirir.

Bu sırayı — artı kategori-içi kapsam sıralamasını (global → controller → method) — bilmek, mantığı doğru bileşene yerleştirmenizi, yürütme akışını tahmin etmenizi, beklendiği zaman (veya zamanında olmadığı zaman) bir şey neden çalıştığını hata ayıklamanızı ve özellikleri doğru şekilde tasarlamanızı sağlar.

Framework'ün tüm istek işleme bileşenlerini (middleware, guard'lar, interceptor'lar, pipe'lar, filter'lar) tutarlı bir zihinsel modele bağlar, bu da NestJS'nin istekleri nasıl işlediğine ilişkin gerçek anlayışı yansıtan önemli, sık test edilen bir konudur.