સીરીયલાઇઝેશન નિયંત્રણ કરે છે કે ઑબ્જેક્ટ્સ રેસ્પોન્સમાં મોકલવામાં આવતા JSON માં કેવી રીતે રૂપાંતરિત થાય છે — અત્યંત મહત્ત્વપૂર્ણ રીતે, સંવેદનશીલ ક્ષેત્રો બાકાત કર્યા (જેમ કે પાસવર્ડ) અને આઉટપુટ આકાર આપવું. NestJS આને ClassSerializerInterceptor અને class-transformer ડેકોરેટર્સ સાથે સંભાળે છે.
()
() {
..(id);
}
ડેટાબેસ એન્ટિટીને સીધું પરત કરવું એવા ક્ષેત્રો પ્રકાશમાં આણી શકે છે જે ક્લાયન્ટ પાસે કદાપि પહોંચવા જોઈએ નહીં (પાસવર્ડ હેશ, આંતરિક ફ્લેગ્સ, ટોકનો) — એક ગંભીર સુરક્ષા/ગોપનીયતા સમસ્યા.
import { Exclude } from "class-transformer";
export class User {
id: number;
name: string;
email: string;
@Exclude() // this field is REMOVED from responses
password: string;
}
// 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 રેસ્પોન્સ સીરીયલાઇઝ કરતી વખતે class-transformer ડેકોરેટર્સ લાગુ કરે છે, તેથી @Exclude() ક્ષેત્રો આપોઆપ દૂર કર્યા જાય છે — પરંતુ માત્ર જો તમે ક્લાસ ઇન્સ્ટાન્સ પરત કર્યા તો (સાદા ઑબ્જેક્ટ્સ નહીં).
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;
}
// ⚠️ 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!
સામાન્ય મુશ્કેલી: સીરીયલાઇઝેશન ડેકોરેટર્સ માત્ર વાસ્તવિક ક્લાસ ઇન્સ્ટાન્સ પર કામ કરે છે, તેથી તમે ઇન્સ્ટાન્સ પરત કરવો જોઈએ (ORM એન્ટિટીઓ સામાન્યતઃ ઇન્સ્ટાન્સ હોય છે; મેન્યુયલી-બનાવેલ સાદા ઑબ્જેક્ટ્સને રૂપાંતર જરૂરી છે).
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.
રેસ્પોન્સ સીરીયલાઇઝેશન નિયંત્રણ કરવું સુરક્ષા અને સ્વચ્છ API ડિઝાઇન બંને માટે મહત્ત્વપૂર્ણ છે.
સૌથી સમીચીન કારણ છે સંવેદનશીલ ડેટા લીક પ્રતિબંધ કરવો — ડેટાબેસ એન્ટિટીને સીધું પરત કરવું પાસવર્ડ હેશ, આંતરિક ક્ષેત્રો, ટોકનો, અથવા અન્ય ડેટા પ્રકાશમાં આણી શકે છે જે ક્લાયન્ટ પાસે કદાપि પહોંચવો જોઈએ નહીં, જે સામાન્ય અને ગંભીર સુરક્ષા ખામી છે.
NestJS નો ClassSerializerInterceptor class-transformer ડેકોરેટર્સ (@Exclude, @Expose, @Transform) સાથે રેસ્પોન્સ આકાર આપવાની સ્વચ્છ, ઘોષણાત્મક રીત પ્રદાન કરે છે — આપોઆપ બાકાત ક્ષેત્રો દૂર કર્યા જાય છે, નાં બદલી દેવાય છે, અને મૂલ્યો રૂપાંતરિત થાય છે.
તમે આ સમજો તે દરેક API માટે અત્યાવશ્યક રોજિંદું જ્ઞાન છે જે વપરાશકર્તા અથવા ડોમેન ડેટા પરત કરે છે, અને મુખ્ય મુશ્કેલી જાણવી — કે સીરીયલાઇઝેશન માત્ર ક્લાસ ઇન્સ્ટાન્સ પર કામ કરે છે, સાદા ઑબ્જેક્ટ્સ પર નહીં ("પાસવર્ડ હજી પણ દેખાય છે કેમ?" બગનો વારંવાર સ્ત્રોત) — વ્યવહારીક રીતે મહત્ત્વપૂર્ણ છે.
સમાન રીતે મૂલ્યવાન છે સમર્પિત રેસ્પોન્સ DTOs પેટર્નને પ્રતિ જાગરણ (એન્ટિટીને સ્પષ્ટ આઉટપુટ ક્લાસમાં મેપ કરવી જેમાં માત્ર ક્લાયન્ટ-સુરક્ષિત ક્ષેત્રો હોય), જે API સંરક્ષણને ડેટાબેસ મોડેલ પરથી અલગ કરે છે અને સંવેદનશીલ ડેટા માટે સૌથી સુરક્ષિત અભિગમ છે.
સીરીયલાઇઝેશન યોગ્યતાથી નિયંત્રણ કરવું સુરક્ષિત, સારી રીતે ડિઝાઇન કરવામાં આવેલ NestJS APIs નો વિશેષતા છે અને બિન-જાહેર ડેટા સંભાળતી કોઈપણ વાસ્તવિક એપ્લિકેશનમાં વારંવાર સુસંગત ચિંતા છે.