NestJS میں request lifecycle کی ترتیب کیا ہے؟

Question

Accepted Answer

**request lifecycle** وہ درست ترتیب ہے جس میں NestJS میں ایک request مختلف components سے گزرتی ہے — middleware، guards، interceptors، pipes، handler، پھر سے interceptors، اور اگر خرابی ہو تو exception filters۔ ہر حصے کی logic کب چلتی ہے اس کو سمجھنا بہت ضروری ہے۔

## مکمل ترتیب

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

## اہمیت

Request lifecycle کی ترتیب کو سمجھنا NestJS applications کو صحیح طریقے سے بنانے کے لیے بنیادی ہے — یہ یقینی بناتا ہے کہ ہر cross-cutting logic بالکل کب چلے گی، جو براہ راست ڈیزائن کے فیصلوں اور debugging کو متاثر کرتا ہے۔

یہ ترتیب واقعی اہم ہے: **guards pipes سے پہلے چلتے ہیں**، تو authorization input کی تصدیق سے پہلے صحیح طریقے سے چیک ہوتی ہے (ایک غیر مجاز request validation سے پہلے رد کر دی جاتی ہے)؛ **pipes صرف handler سے پہلے چلتے ہیں**، یقینی بناتے ہوئے کہ handler ہمیشہ تصدیق شدہ، تبدیل شدہ arguments حاصل کرے؛ **interceptors handler کو محیط میں لیتے ہیں** (پہلے *اور* بعد میں چلتے ہوئے)، جو بالکل ہی انہیں execution کا وقت لگانے اور responses تبدیل کرنے کی اجازت دیتا ہے؛ اور **exception filters کسی بھی مرحلے سے غلطیاں پکڑتے ہیں**، مرکزی error handling کو فعال کرتے ہوئے۔

اس ترتیب کو جاننا — علاوہ اس کے within-category scope ترتیب (global → controller → method) — آپ کو logic کو صحیح component میں رکھنے، execution flow کو پیش گوئی کرنے، debug کرنے کہ کچھ کب (یا کب نہیں) چلتا ہے، اور features کو صحیح طریقے سے بنانے دیتا ہے۔

یہ framework کے تمام request-handling pieces (middleware، guards، interceptors، pipes، filters) کو ایک منطقی ذہنی ماڈل میں جوڑتا ہے، اسے ایک اہم، بار بار آنے والا سوال بناتا ہے جو NestJS request processing کی حقیقی سمجھ ظاہر کرتا ہے۔