Serialization ਇਹ ਕੰਟਰੋਲ ਕਰਦਾ ਹੈ ਕਿ ਆਬਜੈਕਟਸ ਨੂੰ ਜਵਾਬਾਂ ਵਿੱਚ ਭੇਜੇ ਗਏ 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 ਜਵਾਬਾਂ ਨੂੰ serialize ਕਰਦੇ ਸਮੇਂ 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!
ਇੱਕ ਆਮ ਗਲਤੀ: serialization ਡੈਕੋਰੇਟਰ ਸਿਰਫ਼ ਅਸਲ ਕਲਾਸ ਇਨਸਟੈਂਸਜ਼ ਤੇ ਕਾਮ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਇੱਕ ਇਨਸਟੈਂਸ ਵਾਪਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ (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.
Response serialization ਨੂੰ ਕੰਟਰੋਲ ਕਰਨਾ ਸੁਰੱਖਿਆ ਅਤੇ ਸਾਫ਼ API ਡਿਜ਼ਾਈਨ ਦੋਵਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ।
सबसे ਮਹੱਤਵਪੂਰਨ ਕਾਰਨ ਹੈ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਲੀਕਸ ਨੂੰ ਰੋਕਣਾ — ਡਾਟਾਬੇਸ ਇੰਟੀਟੀਜ਼ ਨੂੰ ਸਿੱਧਾ ਵਾਪਸ ਕਰਨਾ ਪਾਸਵਰਡ ਹੈਸ਼, ਅਖਾਤੀ ਫੀਲਡਾਂ, ਟੋਕਨ, ਜਾਂ ਹੋਰ ਡਾਟਾ ਦਾ ਖੁਲਾਸਾ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਕਦੇ ਕਲਾਇਂਟਸ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਣਾ ਚਾਹੀਦਾ, ਇੱਕ ਆਮ ਅਤੇ ਗੰਭੀਰ ਭੇਦਭਾਵ।
NestJS ਦਾ ClassSerializerInterceptor class-transformer ਡੈਕੋਰੇਟਰਾਂ ਨਾਲ (@Exclude, @Expose, @Transform) ਜਵਾਬਾਂ ਨੂੰ ਸ਼ਾਪ ਕਰਨ ਲਈ ਇੱਕ ਸਾਫ਼, ਘੋਸ਼ਣਾਕਾਰੀ ਤਰੀਕਾ ਫ਼ਰਾਹਮ ਕਰਦਾ ਹੈ — ਆਟੋਮੈਟਿਕ ਤੌਰ ਤੇ ਬਾਹਰ ਕੱਢੀਆਂ ਗਈਆਂ ਫੀਲਡਾਂ, ਨਾਮ ਬਦਲਨਾ, ਅਤੇ ਮੁੱਲਾਂ ਨੂੰ ਤਬਦੀਲ ਕਰਨਾ।
ਇਹ ਸਮਝਣਾ ਕਿਸੇ ਵੀ API ਲਈ ਆਮ ਰੋਜ਼ਮਰਾਂ ਦਾ ਜ਼ਰੂਰੀ ਗਿਆਨ ਹੈ ਜੋ ਯੂਜ਼ਰ ਜਾਂ ਡੋਮੇਨ ਡਾਟਾ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਮੁੱਖ ਗਲਤੀ ਨੂੰ ਜਾਣਨਾ — ਕਿ serialization ਸਿਰਫ਼ ਕਲਾਸ ਇਨਸਟੈਂਸਜ਼ ਤੇ ਕਾਮ ਕਰਦਾ ਹੈ, ਸਾਧਾਰਨ ਆਬਜੈਕਟਸ ਤੇ ਨਹੀਂ (ਇੱਕ ਅਕਸਰ "ਪਾਸਵਰਡ ਪਰ ਵੀ ਕਿਉਂ ਦਿਖ ਰਿਹਾ ਹੈ?" ਬਗ ਦਾ ਸਰੋਤ) — ਵਿਹਾਰਕ ਤੌਰ ਤੇ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਸਮਰਪਿਤ response DTOs ਦੇ ਵਿਕਲਪ ਪੈਟਰਨ ਨੂੰ ਪਹਿਚਾਣਨਾ (ਇੰਟੀਟੀਜ਼ ਨੂੰ ਸਿਰਫ ਕਲਾਇਂਟ-ਸੁਰੱਖਤ ਫੀਲਡਾਂ ਵਾਲੀਆਂ ਸਪਸ਼ਟ ਆਉਟਪੁੱਟ ਕਲਾਸਾਂ ਵਿੱਚ ਮੈਪ ਕਰਨਾ), ਜੋ API ਕੌਨਟਰੈਕਟ ਨੂੰ ਡਾਟਾਬੇਸ ਮਾਡਲ ਤੋਂ ਅਲੱਗ ਕਰਦਾ ਹੈ ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਲਈ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅ ਤਰੀਕਾ ਹੈ, ਬਰਾਬਰ ਮੁੱਲਵਾਨ ਹੈ।
Serialization ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕੰਟਰੋਲ ਕਰਨਾ ਸੁਰੱਖਿਅ, ਚੰਗੀ-ਡਿਜ਼ਾਈਨ ਕੀਤੇ NestJS APIs ਦਾ ਇੱਕ ਪਹਿਚਾਨ ਹੈ ਅਤੇ ਕਿਸੇ ਵੀ ਗੈਰ-ਜਨਤਕ ਡਾਟਾ ਨੂੰ ਹੈਂਡਲ ਕਰਨ ਵਾਲੀਆਂ ਅਸਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਅਕਸਰ ਪ্রাসंगिक ਚਿੰਤਾ ਹੈ।