ลำดับวงจรชีวิตของ request ใน NestJS เป็นอย่างไร?

Question

Accepted Answer

**วงจรชีวิตของ request (request lifecycle)** คือลำดับที่แม่นยำขององค์ประกอบที่ request ผ่านใน NestJS — middleware, guard, interceptor, pipe, handler, แล้ว interceptor อีกครั้ง และ exception filter เมื่อเกิด error การรู้ลำดับที่ถูกต้องเป็นสิ่งสำคัญต่อการเข้าใจว่า logic แต่ละชิ้นทำงาน *เมื่อใด*

## ลำดับทั้งหมด

```text
Incoming Request
   │
   ▼
1. MIDDLEWARE            (Express-style; raw req/res; runs first)
   │
   ▼
2. GUARDS                (authorization — return true to continue, false/throw to block)
   │
   ▼
3. INTERCEPTORS (pre)    (logic BEFORE the handler — start timing, etc.)
   │
   ▼
4. PIPES                 (validate/transform the handler's arguments — DTO validation)
   │
   ▼
5. ROUTE HANDLER         (your controller method runs)
   │
   ▼
6. INTERCEPTORS (post)   (logic AFTER the handler — transform the response)
   │
   ▼
Response

✗ If an exception is thrown ANYWHERE above →
7. EXCEPTION FILTERS     (catch it and format the error response)
```

## ทำไมลำดับจึงสำคัญ (ผลในทางปฏิบัติ)

```text
• Guards run BEFORE pipes → authorization is checked before input validation
  (no point validating a body for an unauthorized request)
• Pipes run JUST BEFORE the handler → the handler always gets validated/transformed args
• Interceptors straddle the handler → they can measure its duration and transform output
• Filters catch errors from any stage → centralized, consistent error handling
```

## ภายในแต่ละหมวดหมู่ จะใช้การจัดลำดับตาม scope

```text
For each type (guards, interceptors, pipes), they run in this scope order:
  Global → Controller → Method (route)
So a global guard runs before a controller-level guard, before a route-level guard.
```

## ตัวอย่างที่เป็นรูปธรรม

```ts
@Controller("users")
@UseGuards(AuthGuard)                    // 2. checks authorization
@UseInterceptors(LoggingInterceptor)     // 3 (pre) + 6 (post)
export class UsersController {
  @Post()
  create(@Body() dto: CreateUserDto) {    // 4. ValidationPipe validates dto, 5. handler runs
    return this.usersService.create(dto);
  }
}
// Flow: middleware → AuthGuard → LoggingInterceptor(before) → ValidationPipe →
//       create() → LoggingInterceptor(after) → response (or → filter on error)
```

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

การเข้าใจลำดับวงจรชีวิตของ request เป็นพื้นฐานของการสร้างแอปพลิเคชัน NestJS อย่างถูกต้อง — มันกำหนดอย่างแม่นยำว่า logic แบบ cross-cutting แต่ละชิ้นทำงาน *เมื่อใด* ซึ่งส่งผลโดยตรงต่อการตัดสินใจออกแบบและการ debug

ลำดับนี้มีนัยสำคัญในทางปฏิบัติจริง: **guard ทำงานก่อน pipe** ดังนั้น authorization จึงถูกตรวจสอบอย่างถูกต้องก่อนที่จะเสียเวลา validate input (request ที่ไม่ได้รับอนุญาตถูกปฏิเสธก่อนการ validate); **pipe ทำงานก่อน handler พอดี** รับประกันว่า handler ได้รับ argument ที่ผ่านการ validate และแปลงแล้วเสมอ; **interceptor ห่อหุ้ม handler** (ทำงานทั้งก่อน *และ* หลัง) ซึ่งคือสิ่งที่ทำให้มันจับเวลาการทำงานและแปลง response ได้; และ **exception filter ดักจับ error จากทุกขั้นตอน** ทำให้เกิดการจัดการ error แบบรวมศูนย์

การรู้ลำดับนี้ — รวมถึงการจัดลำดับตาม scope ภายในหมวดหมู่ (global → controller → method) — ทำให้คุณวาง logic ในองค์ประกอบที่ถูกต้อง, คาดการณ์ลำดับการทำงาน, debug ว่าทำไมบางอย่างทำงาน (หรือไม่ทำงาน) เมื่อคาดไว้ และออกแบบฟีเจอร์ได้อย่างถูกต้อง

มันร้อยเรียงชิ้นส่วนการจัดการ request ทั้งหมดของเฟรมเวิร์ก (middleware, guard, interceptor, pipe, filter) เข้าเป็นแบบจำลองความคิดที่สอดคล้องกัน ทำให้เป็นหัวข้อสำคัญที่ถูกทดสอบบ่อยและสะท้อนความเข้าใจที่แท้จริงว่า NestJS ประมวลผล request อย่างไร