Was ist Middleware in NestJS und wie unterscheidet sie sich von Guards/Interceptors?

Question

Accepted Answer

**Middleware** ist eine Funktion, die **vor dem Route Handler** ausgeführt wird und Zugriff auf die Request- und Response-Objekte hat – dasselbe Konzept wie Express Middleware. NestJS hat auch Guards, Interceptors, Pipes und Filters, die jeweils an einem bestimmten Punkt im Request-Lifecycle ausgeführt werden und einen unterschiedlichen Zweck erfüllen. Zu wissen, welches Tool man wann einsetzt, ist der Schlüssel.

## Middleware – läuft zuerst, hat 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 läuft am frühesten ab, vor Guards/Interceptors/Pipes, und arbeitet mit rohem `req`/`res` – geeignet für Logging, Request-Modifikation, CORS und Express-kompatible Aufgaben.

## Die vollständige Request-Lifecycle-Reihenfolge

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

## Wofür jedes da ist (das richtige Tool wählen)

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

Die wesentlichen Unterschiede: Middleware ist generische Express-ähnliche Vorverarbeitung; **Guards** befassen sich speziell mit Autorisierung (ein sauberer, dedizierter Ort für Auth, anders als es in Middleware zu quetschen); **Interceptors** wrappen den Handler, um Responses zu transformieren oder übergreifendes Verhalten zu ergänzen; **Pipes** validieren Input; **Filters** behandeln Fehler.

## Wann man Middleware vs Guards vs Interceptors verwendet

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

## Warum es wichtig ist

Das Verständnis von Middleware und wie sie sich von Guards, Interceptors, Pipes und Filters unterscheidet, ist essentiell für den korrekten Aufbau von NestJS-Anwendungen – jede hat eine spezifische Rolle und läuft an einem bestimmten Punkt im Request-Lifecycle, und die Verwendung des richtigen Tools führt zu sauberem, idiomatischem Code.

Middleware behandelt allgemeine Express-ähnliche Vorverarbeitung mit rohem req/res.

Die entscheidenden Unterschiede sind, dass **Guards** der dedizierte, richtige Ort für Autorisierung sind (Auth/Roles) – viel sauberer als Middleware für diesen Zweck – und **Interceptors** den Handler wrappen, um Responses zu transformieren und übergreifende Anliegen zu ergänzen (Logging, Caching, Timing), was Middleware nicht einfach kann (da sie vor dem Handler läuft und die Response nicht natürlicherweise sieht).

Die Kenntnis der vollständigen Lifecycle-Reihenfolge (Middleware → Guards → Interceptors → Pipes → Handler → Interceptors → Filters) und welches Tool zu welchem Anliegen passt (Auth → Guard, Response-Transformation → Interceptor, Validierung → Pipe, Fehler → Filter) ist ein Zeichen von NestJS-Kompetenz und verhindert den häufigen Fehler, Middleware für alles zu missbrauchen.

Dies ist ein häufig getestetes, architektonisch wichtiges Thema im Framework.