Cos'è il middleware in NestJS e come differisce da guards/interceptors?

Question

Accepted Answer

**Middleware** è una funzione che viene eseguita **prima del route handler**, con accesso agli oggetti request e response — lo stesso concetto del middleware Express. NestJS ha anche guards, interceptors, pipes e filters, ciascuno eseguito in un punto specifico del ciclo di vita della richiesta con uno scopo distinto. Sapere quale usare è fondamentale.

## Middleware — eseguito per primo, ha 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
  }
}
```

Il middleware viene eseguito per primo, prima di guards/interceptors/pipes, e funziona con `req`/`res` grezzi — utile per logging, modifica della richiesta, CORS e problemi compatibili con Express.

## L'ordine completo del ciclo di vita della richiesta

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

## A cosa serve ciascuno (scegliere lo strumento giusto)

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

Le distinzioni chiave: il middleware è un pre-processing generico in stile Express; **guards** gestiscono specificatamente l'autorizzazione (un luogo pulito e dedicato per l'autenticazione, a differenza di inserirla nel middleware); **interceptors** avvolgono il handler per trasformare le risposte o aggiungere comportamenti trasversali; **pipes** validano l'input; **filters** gestiscono gli errori.

## Quando usare 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
```

## Perché è importante

Comprendere il middleware e come differisce da guards, interceptors, pipes e filters è essenziale per strutturare correttamente le applicazioni NestJS — ciascuno ha un ruolo specifico e viene eseguito in un punto specifico del ciclo di vita della richiesta, e usare quello giusto porta a codice pulito e idiomatico.

Il middleware gestisce il pre-processing generico in stile Express con req/res grezzi.

Le distinzioni cruciali sono che **guards** sono il luogo dedicato e appropriato per l'autorizzazione (auth/roles) — molto più pulito del middleware per questo scopo — e **interceptors** avvolgono il handler per trasformare le risposte e aggiungere problematiche trasversali (logging, caching, timing) che il middleware non riesce a fare facilmente (poiché viene eseguito prima del handler e non vede naturalmente la risposta).

Conoscere l'ordine completo del ciclo di vita (middleware → guards → interceptors → pipes → handler → interceptors → filters) e quale strumento si adatta a ogni problema (auth → guard, trasformazione della risposta → interceptor, validazione → pipe, errori → filter) è un segno di competenza in NestJS e previene l'errore comune di abusare del middleware per tutto.

Questa è un'argomento frequentemente testato e architetturalmente importante nel framework.