რა არის NestJS-ის მოთხოვნის ცხოვრების ციკლის თანმიმდევრობა?

Question

Accepted Answer

**მოთხოვნის ცხოვრების ციკლი** არის კომპონენტების ზუსტი თანმიმდევრობა, რომელზეც გადის მოთხოვნა NestJS-ში — middleware, guard, interceptor, pipe, handler, შემდეგ ისევ interceptor, და exception filter შეცდომების დროს. ზუსტი თანმიმდევრობის ცოდნა გადამწყვეტია იმისთვის, რომ გავიგოთ *როდის* გაკეთდება თითოეული ლოგიკის ნაწილი.

## სრული თანმიმდევრობა

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

## რატომ არის მნიშვნელოვანი თანმიმდევრობა (პრაქტიკული შედეგები)

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

## თითოეული კატეგორიის ფარგლებში, scope-ის თანმიმდევრობა ვრცელდება

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

## კონკრეტული მაგალითი

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

## რატომ არის ეს მნიშვნელოვანი

მოთხოვნის ცხოვრების ციკლის თანმიმდევრობის გაგება ფუნდამენტური მნიშვნელობა აქვს NestJS აპლიკაციების სწორად აგებისთვის — ის განსაზღვრავს ზუსტად *როდის* ხორციელდება თითოეული cross-cutting ლოგიკის ნაწილი, რაც პირდაპირი გავლენა ახდენს დიზაინის გადაწყვეტილებებზე და debugging-ზე.

თანმიმდევრობას რეალური პრაქტიკული მნიშვნელობა აქვს: **guard-ები გაშვებულია pipe-ებამდე**, ასე რომ ავტორიზაცია სწორად ხდება შემოწმებული შენმოწმებამდე input-ის (არა ავტორიზირებული მოთხოვნა უარყოფილია validation-მდე); **pipe-ები გაშვებული იქნება handler-ის ზეშემოთ**, რაც უზრუნველყოფს, რომ handler-ი ყოველთვის მიიღებს დამოწმებული და გარდაქმნილი არგუმენტებს; **interceptor-ები ახვევენ handler-ს** (გაშვებული უკან *და* წინ), რაც ზუსტად ის არის, რაც მათ აძლევს შესაძლებლობას, გაზომონ execution და გარდაქმნენ response-ები; და **exception filter-ები ავტომატურადловят ошибки** ნებისმიერი ეტაპიდან, რაც ხელმისაწვდომელს ხდის ცენტრალიზებულ error handling-ს.

ამ თანმიმდევრობის ცოდნა — პლუს scope-ის თანმიმდევრობა კატეგორიის ფარგლებში (გლობალური → controller → method) — გაძლევთ შესაძლებლობას ლოგიკა განათავსოთ სწორ კომპონენტში, predict-ი გააკეთოთ execution flow-ს, debug-ი გააკეთოთ რატომ ხორციელდება (ან არ ხორციელდება) როდის მოსალოდნელი, და სწორად architect-ი გააკეთოთ features.

ეს აერთიანებს framework-ის მოთხოვნის მართვის ყველა ნაწილს (middleware, guard, interceptor, pipe, filter) ერთ თანმიმდევრობითი მენტალური მოდელი, რაც მას ხდის მნიშვნელოვან და ხშირად თეստირებულ საკითხს, რომელიც ასახავს განდეგილი ხელმისაწვდომობას თუ როგორ ამუშავებს NestJS მოთხოვნებს.