Co je middleware v NestJS a jak se liší od guards/interceptors?

Question

Accepted Answer

**Middleware** je funkce, která se spouští **před route handlerem**, s přístupem k objektům request a response — stejný koncept jako Express middleware. NestJS má také guards, interceptory, pipes a filtry, každý se spouští v konkrétním bodu životního cyklu requestu s odlišným účelem. Vědět, který použít, je klíčové.

## Middleware — spouští se jako první, má 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 se spouští nejdříve, před guards/interceptory/pipes, a pracuje se syrými `req`/`res` — dobré pro logging, modifikaci requestu, CORS a Express-kompatibilní věci.

## Úplný pořadí životního cyklu requestu

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

## K čemu každý slouží (volba správného nástroje)

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

Klíčové rozdíly: middleware je generické Express-style předzpracování; **guards** konkrétně zajišťují autorizaci (čisté, dedikované místo pro auth, na rozdíl od zatěžování middleware); **interceptory** obalují handler k transformaci odpovědí nebo přidání cross-cutting chování; **pipes** validují vstup; **filtry** zpracovávají chyby.

## Kdy používat middleware vs guards vs interceptory

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

## Proč to má smysl

Porozumění middleware a tomu, jak se liší od guards, interceptorů, pipes a filtrů, je zásadní pro správnou strukturu NestJS aplikací — každý má specifickou roli a běží v konkrétním bodu životního cyklu requestu, a použití správného z nich vede k čistému, idiomatickému kódu.

Middleware zpracovává obecné Express-style předzpracování se syrými req/res.

Zásadní rozdíly jsou, že **guards** jsou dedikované, správné místo pro autorizaci (auth/role) — mnohem čistší než middleware pro tento účel — a **interceptory** obalují handler k transformaci odpovědí a přidání cross-cutting concern (logging, caching, timing), které middleware nemůže snadno dělat (protože běží před handlerem a přirozeně nevidí odpověď).

Znalost úplného pořadí životního cyklu (middleware → guards → interceptory → pipes → handler → interceptory → filtry) a kterého nástroje se hodí pro kterou věc (auth → guard, transformace odpovědi → interceptor, validace → pipe, chyby → filter) je hallmarkem NestJS kompetence a zabraňuje běžné chybě zneužívání middleware na všechno.

Toto je často testované, architektonicky důležité téma v frameworku.