Mi a middleware a NestJS-ben és miben különbözik a guardoktól/interceptoroktól?

Question

Accepted Answer

**Middleware** egy olyan függvény, amely **az útvonal kezelő előtt** fut, hozzáféréssel a kérés és válasz objektumokhoz — ugyanez a fogalom, mint az Express middleware. A NestJS-nek van továbbá guards, interceptors, pipes és filters is, melyek mindegyike a kérés életciklusa egy adott pontján fut le különböző céllal. Tudni, melyiket kell használni, kulcsfontosságú.

## Middleware — először fut, van 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
  }
}
```

A middleware először fut, a guardok/interceptorok/pipes előtt, és nyers `req`/`res`-sel dolgozik — jó a naplózáshoz, kérés módosításához, CORS-hoz és Express-kompatibilis problémákhoz.

## A teljes kérés-életciklus sorrend

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

## Mire való mindegyik (a megfelelő eszköz kiválasztása)

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

A fő különbségek: a middleware általános Express-stílusú előfeldolgozás; a **guardok** specifikusan az engedélyezést kezelik (tiszta, dedikált hely az auth számára, szemben azzal, hogy a middlewaréba tesszük); az **interceptorok** burkolják a kezelőt a válaszok átalakításához vagy keresztirányú viselkedés hozzáadásához; a **pipeok** validálják a bemenetet; a **filterek** kezelik a hibákat.

## Mikor kell middleware-t vs guardokat vs interceptorokat használni

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

## Miért fontos ez

A middleware megértése és annak ismerete, hogy miben különbözik a guardoktól, interceptoroktól, pipeoktól és filtereketől, elengedhetetlen a NestJS-alkalmazások helyes strukturálásához — mindegyiknek megvan a maga specifikus szerepe és a kérés-életciklus egy adott pontján fut le, és a megfelelő használata tiszta, idiomatikus kódhoz vezet.

A middleware az általános Express-stílusú előfeldolgozást kezeli nyers req/res-sel.

A lényeges különbségek, hogy a **guardok** az engedélyezésnek (auth/roles) dedikált, megfelelő helye — a middleware-hez képest sokkal tisztább erre a célra — és az **interceptorok** burkolják a kezelőt a válaszok átalakításához és keresztirányú problémák (naplózás, gyorsítótárazás, időmérés) hozzáadásához, amit a middleware nem tud könnyen megtenni (mivel az kezelő előtt fut és nem lát természetes választ).

A teljes ciklus sorrendjét (middleware → guardok → interceptorok → pipeok → kezelő → interceptorok → filterek) és azt, melyik eszköz mely problémához illik (auth → guard, válasz átalakítása → interceptor, validálás → pipe, hibák → filter), ismerni a NestJS-kompetencia jele, és megakadályozza a middleware mindenhol való helytelen használatának gyakori hibáját.

Ez egy gyakran tesztelt, architekturálisan fontos topic a framework-ben.