Co to jest middleware w NestJS i czym się różni od guards/interceptors?

Question

Accepted Answer

**Middleware** to funkcja, która działa **przed obsługą trasy**, mając dostęp do obiektów żądania i odpowiedzi — ten sam koncept co middleware Express. NestJS posiada również guards, interceptory, pipes i filtry, z których każdy działa w konkretnym punkcie cyklu życia żądania z odrębnym celem. Wiedza, które narzędzie użyć, jest kluczowa.

## Middleware — działa jako pierwszy, ma dostęp do 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 działa najwcześniej, przed guards/interceptors/pipes, i pracuje z raw `req`/`res` — przydatny do logowania, modyfikacji żądań, CORS i obaw kompatybilnych z Express.

## Pełny porządek cyklu życia żądania

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

## Co każdy robi (wybieranie odpowiedniego narzędzia)

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

Kluczowe rozróżnienia: middleware to generyczne przetwarzanie wstępne w stylu Express; **guards** konkretnie zajmują się autoryzacją (czysty, dedykowany do tego celu — inaczej niż zapchacie go middleware); **interceptory** owijają obsługę aby transformować odpowiedzi lub dodać zachowania cross-cutting; **pipes** walidują input; **filtry** obsługują błędy.

## Kiedy używać 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
```

## Dlaczego to ważne

Zrozumienie middleware i jego różnic od guards, interceptors, pipes i filtrów jest niezbędne do prawidłowej strukturyzacji aplikacji NestJS — każdy ma konkretną rolę i działa w konkretnym punkcie cyklu życia żądania, a użycie odpowiedniego prowadzi do czystego, idiomatycznego kodu.

Middleware obsługuje ogólne przetwarzanie wstępne w stylu Express z raw req/res.

Krucjalne rozróżnienia to **guards** — dedykowane, właściwe miejsce dla autoryzacji (auth/role) — znacznie czystsze niż middleware do tego celu — i **interceptory** owijające obsługę aby transformować odpowiedzi i dodawać cross-cutting concerns (logowanie, cache'owanie, pomiary), których middleware nie może łatwo robić (ponieważ działa przed obsługą i naturalnie nie widzi odpowiedzi).

Znajomość pełnego porządku cyklu życia (middleware → guards → interceptory → pipes → obsługa → interceptory → filtry) i które narzędzie pasuje do każdego problemu (auth → guard, transformacja odpowiedzi → interceptor, walidacja → pipe, błędy → filter) jest oznaką kompetencji w NestJS i zapobiega powszechnemu błędowi niewłaściwego użycia middleware do wszystkiego.

To jest często testowany, architektonicznie ważny temat w frameworku.