คุณควบคุมการ serialize response ใน NestJS อย่างไร?

Question

Accepted Answer

**Serialization** ควบคุมว่าออบเจ็กต์จะถูกแปลงเป็น JSON ที่ส่งใน response อย่างไร โดยที่สำคัญยิ่งคือการ **ตัด field ที่ละเอียดอ่อนออก** (เช่น password) และกำหนดรูปร่างของ output NestJS จัดการเรื่องนี้ด้วย `ClassSerializerInterceptor` และเดคอเรเตอร์ของ `class-transformer`

## ปัญหา: ข้อมูลละเอียดอ่อนรั่วไหล

```ts
// ❌ returning an entity directly leaks the password hash!
@Get(":id")
findOne(@Param("id") id: string) {
  return this.usersService.findOne(id);   // { id, name, email, password: "$2b$..." } 😱
}
```

การคืน entity ของ database โดยตรงอาจเปิดเผย field ที่ไม่ควรไปถึง client เลย (password hash, internal flag, token) ซึ่งเป็นปัญหาด้านความปลอดภัย/ความเป็นส่วนตัวที่ร้ายแรง

## ทางแก้: @Exclude และ ClassSerializerInterceptor

```ts
import { Exclude } from "class-transformer";

export class User {
  id: number;
  name: string;
  email: string;

@Exclude()                    // this field is REMOVED from responses
  password: string;
}
```

```ts
// enable the serializer interceptor (globally or per-controller)
@UseInterceptors(ClassSerializerInterceptor)
@Controller("users")
export class UsersController {
  @Get(":id")
  findOne(@Param("id") id): User {
    return this.usersService.findOne(id);   // password is automatically stripped
  }
}
// or globally: app.useGlobalInterceptors(new ClassSerializerInterceptor(app.get(Reflector)))
```

`ClassSerializerInterceptor` จะ apply เดคอเรเตอร์ของ `class-transformer` ขณะ serialize response ทำให้ field ที่มี `@Exclude()` ถูกตัดออกโดยอัตโนมัติ แต่ **เฉพาะเมื่อคุณคืน class instance** (ไม่ใช่ออบเจ็กต์ธรรมดา) เท่านั้น

## เดคอเรเตอร์การแปลงเพิ่มเติม

```ts
export class User {
  @Expose()  id: number;          // explicitly include (with excludeAll strategy)
  @Exclude() password: string;     // remove from output

@Expose({ name: "full_name" })   // rename in the output
  name: string;

@Transform(({ value }) => value.toUpperCase())   // transform the value
  code: string;

@Exclude({ toPlainOnly: true })  // exclude only when serializing OUT (not on input)
  internalField: string;
}
```

## ต้องคืน class instance

```ts
// ⚠️ the interceptor only transforms CLASS INSTANCES — plain objects pass through unchanged
return new User(data);                 // ✅ decorators apply
return plainToInstance(User, data);     // ✅ convert a plain object to an instance
return { ...data };                     // ❌ plain object — @Exclude is IGNORED!
```

กับดักที่พบบ่อย: เดคอเรเตอร์ serialization ทำงานเฉพาะกับ class instance จริงเท่านั้น ดังนั้นคุณต้องคืน instance (entity ของ ORM มักเป็น instance อยู่แล้ว แต่ออบเจ็กต์ธรรมดาที่สร้างเองต้องแปลงก่อน)

## ทางเลือก: response DTO เฉพาะ

```text
Instead of decorating entities, map to a separate Response DTO containing only the
fields meant for the client — explicit, decoupled from the DB model, and very safe.
```

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

การควบคุมการ serialize response สำคัญทั้งต่อ **ความปลอดภัย** และการออกแบบ API ที่สะอาด

เหตุผลที่สำคัญที่สุดคือการป้องกัน **การรั่วไหลของข้อมูลละเอียดอ่อน** การคืน entity ของ database โดยตรงอาจเปิดเผย password hash, internal field, token หรือข้อมูลอื่นที่ไม่ควรไปถึง client เลย ซึ่งเป็นช่องโหว่ที่พบบ่อยและร้ายแรง

`ClassSerializerInterceptor` ของ NestJS ร่วมกับเดคอเรเตอร์ของ `class-transformer` (`@Exclude`, `@Expose`, `@Transform`) มอบวิธีกำหนดรูปร่าง response แบบ declarative ที่สะอาด โดยตัด field ที่ถูก exclude, เปลี่ยนชื่อ และแปลงค่าโดยอัตโนมัติ

การเข้าใจสิ่งนี้เป็นความรู้ในชีวิตประจำวันที่จำเป็นสำหรับ API ใดก็ตามที่คืนข้อมูลของผู้ใช้หรือ domain และการรู้กับดักสำคัญ คือ **serialization ทำงานเฉพาะกับ class instance ไม่ใช่ออบเจ็กต์ธรรมดา** (ต้นเหตุที่พบบ่อยของบั๊ก "ทำไม password ยังโผล่อยู่?") มีความสำคัญเชิงปฏิบัติ

ที่มีค่าพอกันคือการตระหนักถึงแพทเทิร์นทางเลือกของ **response DTO เฉพาะ** (การ map entity เป็นคลาส output ที่ชัดเจนซึ่งมีเฉพาะ field ที่ปลอดภัยสำหรับ client) ซึ่ง decouple สัญญา (contract) ของ API ออกจากโมเดล database และเป็นแนวทางที่ปลอดภัยที่สุดสำหรับข้อมูลละเอียดอ่อน

การควบคุม serialization อย่างถูกต้องเป็นเครื่องหมายของ NestJS API ที่ปลอดภัยและออกแบบมาอย่างดี และเป็นข้อกังวลที่เกี่ยวข้องบ่อยในแอปพลิเคชันจริงที่จัดการข้อมูลที่ไม่เปิดเผยต่อสาธารณะใดๆ