Middleware trong NestJS là gì và nó khác guard/interceptor như thế nào?

Question

Accepted Answer

**Middleware** là một hàm chạy **trước route handler**, có quyền truy cập vào các đối tượng request và response — cùng khái niệm với Express middleware. NestJS cũng có guard, interceptor, pipe và filter, mỗi cái chạy tại một điểm cụ thể trong vòng đời request với một mục đích riêng biệt. Biết dùng cái nào là then chốt.

## Middleware — chạy đầu tiên, có req/res

```ts
@Injectable()
export class LoggerMiddleware implements NestMiddleware {
  use(req: Request, res: Response, next: NextFunction) {
    console.log(`${req.method} ${req.url}`);   // ghi log, sửa đổi req
    next();                                      // PHẢI gọi next() để tiếp tục
  }
}

// đăng ký trong một module
export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer) {
    consumer.apply(LoggerMiddleware).forRoutes("*");   // áp dụng cho route
  }
}
```

Middleware chạy sớm nhất, trước guard/interceptor/pipe, và làm việc với `req`/`res` thô — tốt cho logging, sửa đổi request, CORS, và các mối quan tâm tương thích với Express.

## Thứ tự đầy đủ của vòng đời request

```text
Request →
  1. Middleware     (req/res; chạy đầu tiên, kiểu Express)
  2. Guards         (trả về true/false → CHO PHÉP hoặc chặn request)
  3. Interceptors   (TRƯỚC handler)
  4. Pipes          (validate/biến đổi các argument của handler)
  5. → Route Handler ←
  6. Interceptors   (SAU handler — biến đổi response)
  7. Exception Filters (nếu một lỗi được ném ra ở bất kỳ đâu)
→ Response
```

## Mỗi cái DÙNG ĐỂ làm gì (chọn đúng công cụ)

```text
Middleware  → tiền xử lý chung với req/res (logging, CORS, làm việc với request thô)
Guards      → PHÂN QUYỀN — quyết định request có được tiếp tục không (auth, role)
              (trả về true = cho phép, false/ném = chặn)
Interceptors→ bao bọc handler — biến đổi request/response, thêm logging/caching/timing
              (có thể chạy logic TRƯỚC và SAU handler)
Pipes       → VALIDATE/BIẾN ĐỔI các argument input của handler (validate DTO)
Filters     → bắt và định dạng EXCEPTION thành response
```

Các khác biệt then chốt: middleware là tiền xử lý chung kiểu Express; **guard** xử lý cụ thể việc phân quyền (một nơi sạch sẽ, chuyên dụng cho auth, không như việc nhồi nhét nó vào middleware); **interceptor** bao bọc handler để biến đổi response hoặc thêm hành vi xuyên suốt; **pipe** validate input; **filter** xử lý lỗi.

## Khi nào dùng middleware vs guard vs interceptor

```text
Kiểm tra auth?        → Guard (chuyên dụng, có execution context, trả về boolean)
Ghi log request?      → Middleware HOẶC interceptor (interceptor thấy cả response)
Biến đổi response?    → Interceptor (chạy sau handler)
Validate một DTO?     → Pipe
Sửa req thô sớm?      → Middleware
```

## Tại sao điều này quan trọng

Hiểu middleware và cách nó khác guard, interceptor, pipe và filter là thiết yếu để cấu trúc các ứng dụng NestJS đúng đắn — mỗi cái có một vai trò cụ thể và chạy tại một điểm cụ thể trong vòng đời request, và dùng đúng cái dẫn đến code sạch sẽ, thành ngữ.

Middleware xử lý tiền xử lý chung kiểu Express với req/res thô.

Các khác biệt quan trọng là **guard** là nơi chuyên dụng, đúng đắn cho phân quyền (auth/role) — sạch sẽ hơn nhiều so với middleware cho mục đích đó — và **interceptor** bao bọc handler để biến đổi response và thêm các mối quan tâm xuyên suốt (logging, caching, timing) mà middleware không dễ làm (vì nó chạy trước handler và không tự nhiên thấy được response).

Biết thứ tự vòng đời đầy đủ (middleware → guard → interceptor → pipe → handler → interceptor → filter) và công cụ nào phù hợp với mỗi mối quan tâm (auth → guard, biến đổi response → interceptor, validation → pipe, lỗi → filter) là dấu ấn của năng lực NestJS và ngăn ngừa sai lầm phổ biến của việc lạm dụng middleware cho mọi thứ.

Đây là một chủ đề thường được hỏi, quan trọng về mặt kiến trúc trong framework.