NestJS मा middleware भनेको के हो र यो guards/interceptors बाट कसरी फरक छ?

Question

Accepted Answer

**Middleware** एक function हो जो **route handler को अगाडि** चल्छ, request र response objects मा पहुँच भएको — यो Express middleware को जस्तै concept हो। 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-compatible concerns को लागि राम्रो छ।

## पूरो request lifecycle order

```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 को लपेटिन्छन् response transform गर्न वा cross-cutting behavior थप्न; **pipes** input validate गर्छन्; **filters** errors सम्हाल्छन्।

## कहिले middleware vs guards vs 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 सामान्य Express-style pre-processing लाई raw req/res सँग सम्हाल्छ।

मुख्य फरकहरु यो हुन् कि **guards** authorization को लागि समर्पित, उचित जागा हुन् (auth/roles) — middleware को तुलनामा त्यो उद्देश्यको लागि धेरै स्वच्छ — र **interceptors** handler लाई लपेटिन्छन् responses transform गर्न र cross-cutting concerns थप्न (logging, caching, timing) जो middleware गर्न सक्दैन (किनकि यो handler अगाडि चल्छ र response प्राकृतिक रुपमा देख्दैन)।

पूरो lifecycle order (middleware → guards → interceptors → pipes → handler → interceptors → filters) र कुन tool कुन concern को लागि फिट छ (auth → guard, response transformation → interceptor, validation → pipe, errors → filter) भनेर जान्नु NestJS competence को एक विशेषता हो र middleware लाई सबै कुरामा गलत प्रयोग गर्ने सामान्य गल्ती रोक्छ।

यो एक बारम्बार-परीक्षण गरिएको, architecturally-महत्त्वपूर्ण topic framework मा छ।