NestJS-இல் response serialization-ஐ எப்படிக் கட்டுப்படுத்துவீர்கள்?

Question

Accepted Answer

**Serialization** ஆனது responses-இல் அனுப்பப்படும் JSON ஆக objects எவ்வாறு மாற்றப்படுகின்றன என்பதைக் கட்டுப்படுத்துகிறது — முக்கியமாக, **முக்கியமான fields-ஐ விலக்குதல்** (passwords போல) மற்றும் output-ஐ வடிவமைத்தல். NestJS இதை `ClassSerializerInterceptor` மற்றும் `class-transformer` decorators மூலம் கையாளுகிறது.

## சிக்கல்: முக்கியமான data கசிதல்

```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$..." } 😱
}
```

Database entities-ஐ நேரடியாகத் திருப்பித் தருவது client-ஐ ஒருபோதும் அடையக்கூடாத fields-ஐ (password hashes, internal flags, tokens) வெளிப்படுத்த முடியும் — ஒரு கடுமையான security/privacy சிக்கல்.

## தீர்வு: @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` ஆனது responses-ஐ serialize செய்யும்போது `class-transformer` decorators-ஐ பயன்படுத்துகிறது, எனவே `@Exclude()` fields தானாகவே நீக்கப்படுகின்றன — ஆனால் **நீங்கள் class instances-ஐத் திருப்பித் தந்தால் மட்டுமே** (plain objects அல்ல).

## மேலும் transformation decorators

```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 instances-ஐ திருப்பித் தர வேண்டும்

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

ஒரு பொதுவான gotcha: serialization decorators உண்மையான class instances-இல் மட்டுமே வேலை செய்கின்றன, எனவே நீங்கள் ஒரு instance-ஐத் திருப்பித் தர வேண்டும் (ORM entities பொதுவாக instances; கையால் கட்டப்பட்ட plain objects-க்கு மாற்றம் தேவை).

## மாற்று: dedicated response DTOs

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

## இது ஏன் முக்கியம்

Response serialization-ஐக் கட்டுப்படுத்துவது **security** மற்றும் சுத்தமான API வடிவமைப்பு இரண்டிற்கும் முக்கியம்.

மிக முக்கியமான காரணம் **முக்கியமான data கசிவுகளைத்** தடுப்பதாகும் — database entities-ஐ நேரடியாகத் திருப்பித் தருவது password hashes, internal fields, tokens, அல்லது clients-ஐ ஒருபோதும் அடையக்கூடாத பிற data-ஐ வெளிப்படுத்த முடியும், இது ஒரு பொதுவான மற்றும் கடுமையான vulnerability.

NestJS-இன் `ClassSerializerInterceptor` உடன் `class-transformer` decorators (`@Exclude`, `@Expose`, `@Transform`) responses-ஐ வடிவமைக்க ஒரு சுத்தமான, declarative வழியை வழங்குகின்றன — விலக்கப்பட்ட fields-ஐ தானாகவே நீக்கி, மறுபெயரிட்டு, மற்றும் values-ஐ transform செய்தல்.

User அல்லது domain data-ஐத் திருப்பித் தரும் எந்த API-க்கும் இதைப் புரிந்துகொள்வது அவசியமான தினசரி அறிவாகும், மேலும் முக்கிய gotcha-ஐ — **serialization plain objects அல்ல, class instances-இல் மட்டுமே வேலை செய்கிறது** ("ஏன் password இன்னும் காட்டப்படுகிறது?" bugs-இன் அடிக்கடி வரும் ஆதாரம்) — அறிந்திருப்பது நடைமுறையில் முக்கியம்.

**Dedicated response DTOs** என்ற மாற்று pattern-ஐ அங்கீகரிப்பதும் (entities-ஐ client-safe fields மட்டுமே கொண்ட explicit output classes-க்கு மேப் செய்தல்), API contract-ஐ database model-இலிருந்து decouple செய்வதும் சமமாக மதிப்புமிக்கது, இது முக்கியமான data-க்கான பாதுகாப்பான அணுகுமுறை.

Serialization-ஐ சரியாகக் கட்டுப்படுத்துவது பாதுகாப்பான, நன்கு வடிவமைக்கப்பட்ட NestJS APIs-இன் அடையாளமாகும், மேலும் எந்த public அல்லாத data-ஐயும் கையாளும் உண்மையான applications-இல் அடிக்கடி தொடர்புடைய கவலையாகும்.