NestJS मध्ये middleware म्हणजे काय आणि ते guards/interceptors पेक्षा कसे वेगळे आहे?

Question

Accepted Answer

**Middleware** हा एक function आहे जो **route handler पूर्वी** चालतो, request आणि response objects मध्ये access असते — 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-compatible concerns साठी चांगले आहे.

## संपूर्ण 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 हा generic Express-style pre-processing आहे; **guards** विशेषत: authorization हाताळतात (auth साठी एक स्वच्छ, समर्पित जागा, middleware मध्ये ते ठेवण्याच्या विरुद्ध); **interceptors** handler ला wrap करतात responses 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
```

## हे का महत्वाचे आहे

NestJS applications योग्यरित्या structure करण्यासाठी middleware आणि ते guards, interceptors, pipes, आणि filters पेक्षा कसे वेगळे आहे हे समजणे आवश्यक आहे — प्रत्येकाचा विशिष्ट भूमिका आहे आणि request lifecycle मध्ये विशिष्ट बिंदूवर चालते, आणि योग्य एक वापरल्यास स्वच्छ, idiomatic code तयार होते.

Middleware raw req/res सह सामान्य Express-style pre-processing हाताळते.

निर्णायक फरक हे आहे की **guards** authorization (auth/roles) साठी समर्पित, योग्य जागा आहेत — त्या उद्देशासाठी middleware पेक्षा खूप स्वच्छ — आणि **interceptors** handler ला wrap करतात responses transform करण्यासाठी आणि 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 सर्वकाहीसाठी वापरण्याची सामान्य चूक रोखते.

हा एक वारंवार-tested, architecturally-important topic framework मध्ये आहे.