Middleware ใน NestJS คืออะไรและแตกต่างจาก guard/interceptor อย่างไร?

Question

Accepted Answer

**Middleware** คือฟังก์ชันที่ทำงาน **ก่อน route handler** โดยมีสิทธิ์เข้าถึง object ของ request และ response — แนวคิดเดียวกับ middleware ของ Express NestJS ยังมี guard, interceptor, pipe และ filter ซึ่งแต่ละตัวทำงาน ณ จุดเฉพาะในวงจรชีวิตของ request โดยมีจุดประสงค์ที่ต่างกัน การรู้ว่าจะใช้ตัวไหนเป็นกุญแจสำคัญ

## Middleware — ทำงานก่อน มี 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 ทำงานเร็วที่สุด ก่อน guard/interceptor/pipe และทำงานกับ `req`/`res` ดิบ — เหมาะสำหรับ logging, การแก้ไข request, CORS และเรื่องที่เข้ากันได้กับ Express

## ลำดับวงจรชีวิตของ request ทั้งหมด

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

## แต่ละตัวมีไว้เพื่ออะไร (การเลือกเครื่องมือที่ถูกต้อง)

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

ความแตกต่างสำคัญ: middleware เป็น pre-processing ทั่วไปแบบ Express; **guard** จัดการ authorization โดยเฉพาะ (ที่ ๆ สะอาดและเฉพาะทางสำหรับ auth ไม่ใช่ยัดมันลงใน middleware); **interceptor** ห่อหุ้ม handler เพื่อแปลง response หรือเพิ่มพฤติกรรมแบบ cross-cutting; **pipe** validate input; **filter** จัดการ error

## เมื่อใดควรใช้ middleware เทียบกับ guard เทียบกับ interceptor

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

## ทำไมจึงสำคัญ

การเข้าใจ middleware และความแตกต่างจาก guard, interceptor, pipe และ filter เป็นสิ่งจำเป็นต่อการจัดโครงสร้างแอปพลิเคชัน NestJS อย่างถูกต้อง — แต่ละตัวมีบทบาทเฉพาะและทำงาน ณ จุดเฉพาะในวงจรชีวิตของ request และการใช้ตัวที่ถูกต้องนำไปสู่โค้ดที่สะอาดและตามแบบฉบับ

Middleware จัดการ pre-processing ทั่วไปแบบ Express ด้วย req/res ดิบ

ความแตกต่างที่สำคัญคือ **guard** เป็นที่ ๆ เฉพาะและเหมาะสมสำหรับ authorization (auth/roles) — สะอาดกว่า middleware มากสำหรับจุดประสงค์นั้น — และ **interceptor** ห่อหุ้ม handler เพื่อแปลง response และเพิ่มเรื่อง cross-cutting (logging, caching, timing) ที่ middleware ทำได้ยาก (เพราะมันทำงานก่อน handler และไม่เห็น response โดยธรรมชาติ)

การรู้ลำดับวงจรชีวิตทั้งหมด (middleware → guard → interceptor → pipe → handler → interceptor → filter) และว่าเครื่องมือไหนเหมาะกับเรื่องไหน (auth → guard, การแปลง response → interceptor, validation → pipe, error → filter) เป็นเครื่องหมายของความสามารถใน NestJS และป้องกันความผิดพลาดที่พบบ่อยของการใช้ middleware กับทุกอย่าง

นี่เป็นหัวข้อที่ถูกทดสอบบ่อยและสำคัญทางสถาปัตยกรรมในเฟรมเวิร์ก