Vad är middleware i NestJS och hur skiljer det sig från guards/interceptors?

Question

Accepted Answer

**Middleware** är en funktion som körs **före route-hanteraren**, med åtkomst till request- och response-objekten — samma koncept som Express middleware. NestJS har även guards, interceptors, pipes och filters, vilka varje körning vid en specifik punkt i request-livscykeln med ett distinkt syfte. Att veta vilken man ska använda är nyckeln.

## Middleware — körs först, har 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 körs tidigast, före guards/interceptors/pipes, och fungerar med råa `req`/`res` — bra för loggning, request-modifiering, CORS och Express-kompatibla angelägenheter.

## Den fullständiga request-livscyklens ordning

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

## Vad varje är för (välja rätt verktyg)

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

De viktiga skillnaderna: middleware är generisk Express-stil förbehandling; **guards** hanterar specifikt auktorisering (en ren, dedikerad plats för autentisering, till skillnad från att stoppa det i middleware); **interceptors** omsluter hanteraren för att transformera svar eller lägga till tvärsnittande beteende; **pipes** validerar inmatning; **filters** hanterar fel.

## När man ska använda 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
```

## Varför det är viktigt

Att förstå middleware och hur det skiljer sig från guards, interceptors, pipes och filters är väsentligt för att strukturera NestJS-applikationer korrekt — varje har en specifik roll och körs vid en specifik punkt i request-livscykeln, och att använda rätt verktyg leder till ren, idiomatisk kod.

Middleware hanterar generell Express-stil förbehandling med råa req/res.

De avgörande skillnaderna är att **guards** är den dedikerade, riktiga platsen för auktorisering (auth/roller) — långt renare än middleware för det syftet — och **interceptors** omsluter hanteraren för att transformera svar och lägga till tvärsnittande angelägenheter (loggning, cachning, tidsmätning) som middleware inte enkelt kan göra (eftersom det körs före hanteraren och inte naturligt ser svaret).

Att känna till den fullständiga livscyklordningen (middleware → guards → interceptors → pipes → handler → interceptors → filters) och vilket verktyg som passar för varje angelägenhet (auth → guard, svar-transformering → interceptor, validering → pipe, fel → filter) är en kännetecken på NestJS-kompetens och förhindrar det vanliga misstaget att missbruka middleware för allt.

Detta är ett vanligt testat, arkitekturellt viktigt ämne i ramverket.