NestJS میں middleware کیا ہے اور یہ guards/interceptors سے کس طرح مختلف ہے؟

Question

Accepted Answer

**Middleware** ایک function ہے جو **route handler سے پہلے** چلتا ہے، request اور response objects تک رسائی کے ساتھ — یہ Express middleware کے جیسا ہی تصور ہے۔ NestJS میں guards، interceptors، pipes، اور filters بھی ہیں، ہر ایک request lifecycle میں ایک مخصوص نقطے پر چلتا ہے اور ایک منفرد مقصد کے ساتھ۔ کون سا استعمال کریں یہ جاننا اہم ہے۔

## Middleware — پہلے چلتا ہے، req/res تک رسائی ہے

```ts
@Injectable()
export class LoggerMiddleware implements NestMiddleware {
  use(req: Request, res: Response, next: NextFunction) {
    console.log(`${req.method} ${req.url}`);   // logging, modifying req
    next();                                      // MUST call next() to continue
  }
}

// register in a module
export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer) {
    consumer.apply(LoggerMiddleware).forRoutes("*");   // apply to routes
  }
}
```

Middleware سب سے پہلے چلتا ہے، guards/interceptors/pipes سے پہلے، اور raw `req`/`res` کے ساتھ کام کرتا ہے — logging، request modification، CORS، اور Express سے ملتی جلتی چیزوں کے لیے اچھا ہے۔

## مکمل request lifecycle کی ترتیب

```text
Request →
  1. Middleware     (req/res; runs first, Express-style)
  2. Guards         (return true/false → AUTHORIZE or block the request)
  3. Interceptors   (BEFORE the handler)
  4. Pipes          (validate/transform the handler's arguments)
  5. → Route Handler ←
  6. Interceptors   (AFTER the handler — transform the response)
  7. Exception Filters (if an error was thrown anywhere)
→ Response
```

## ہر ایک کس لیے ہے (صحیح tool کا انتخاب)

```text
Middleware  → general pre-processing with req/res (logging, CORS, raw request work)
Guards      → AUTHORIZATION — decide if a request may proceed (auth, roles)
              (return true = allow, false/throw = block)
Interceptors→ wrap the handler — transform request/response, add logging/caching/timing
              (can run logic BEFORE and AFTER the handler)
Pipes       → VALIDATE/TRANSFORM the handler's input arguments (DTO validation)
Filters     → catch and format EXCEPTIONS into responses
```

اہم امتیازات: middleware عام Express-style pre-processing ہے؛ **guards** خاص طور پر authorization کو سنبھالتے ہیں (auth کے لیے ایک صاف، مخصوص جگہ، middleware میں ڈالنے سے بہتر)؛ **interceptors** handler کو wrap کرتے ہیں responses کو تبدیل کرنے یا cross-cutting behavior شامل کرنے کے لیے؛ **pipes** input validate کرتے ہیں؛ **filters** errors سنبھالتے ہیں۔

## Middleware بمقابلہ guards بمقابلہ interceptors کب استعمال کریں

```text
Auth check?           → Guard (dedicated, has execution context, returns boolean)
Logging requests?     → Middleware OR an interceptor (interceptor sees the response too)
Transform responses?  → Interceptor (runs after the handler)
Validate a DTO?       → Pipe
Modify raw req early?  → Middleware
```

## یہ کیوں اہم ہے

Middleware کو سمجھنا اور یہ جاننا کہ یہ guards، interceptors، pipes، اور filters سے کس طرح مختلف ہے، NestJS applications کو صحیح طریقے سے ڈھانچہ دینے کے لیے ضروری ہے — ہر ایک کا ایک مخصوص کردار ہے اور request lifecycle میں ایک مخصوص نقطے پر چلتا ہے، اور صحیح tool استعمال کرنا صاف، idiomatic code کی طرف لے جاتا ہے۔

Middleware raw req/res کے ساتھ عام Express-style pre-processing سنبھالتا ہے۔

اہم امتیازات یہ ہیں کہ **guards** authorization کے لیے مخصوص اور مناسب جگہ ہیں (auth/roles) — middleware میں اس مقصد کے لیے بہت زیادہ صاف — اور **interceptors** handler کو wrap کرتے ہیں responses کو تبدیل کرنے اور cross-cutting concerns شامل کرنے کے لیے (logging، caching، timing) جو middleware آسانی سے نہیں کر سکتا (کیونکہ یہ handler سے پہلے چلتا ہے اور قدرتی طور پر response نہیں دیکھتا)۔

مکمل lifecycle کی ترتیب جاننا (middleware → guards → interceptors → pipes → handler → interceptors → filters) اور کون سا tool ہر concern کے لیے فٹ بیٹھتا ہے (auth → guard، response transformation → interceptor، validation → pipe، errors → filter) NestJS competence کی علامت ہے اور middleware کو سب کچھ کے لیے غلط استعمال کرنے کی عام غلطی سے بچاتا ہے۔

یہ ایک بار بار ٹیسٹ کیا جانے والا، architecturally-اہم موضوع framework میں ہے۔