Serializimi kontrollon se si objektet shndërrohen në JSON që dërgon në përgjigje — në mënyrë kritike, përjashton fushat sensitive (si fjalëkalimet) dhe formon daljen. NestJS e menaxhon këtë me ClassSerializerInterceptor dhe dekoratorët e class-transformer.
()
() {
..(id);
}
Kthimi i drejtpërdrejtë i entiteteve të bazës së të dhënave mund të ekspozojë fusha që nuk duhet të arrijnë nëklient (hash të fjalëkalimit, flamuj të brendshëm, token) — një çështje serioze sigurie/privatësie.
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 zbaton dekoratorët e class-transformer kur serializon përgjigjet, kështu që fushat @Exclude() hiqen automatikisht — por vetëm nëse ktheni instanca klase (jo objekte të thjesht).
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!
Një gotcha i zakonshëm: dekoratorët e serializimit funksionojnë vetëm në instanca aktuale klase, kështu që duhet të ktheni një instancë (entitetet ORM janë zakonisht instanca; objektet e ndërtuara manualisht të thjesht kanë nevojë për konvertim).
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.
Kontrollimi i serializimit të përgjigjeve është i rëndësishëm si për sigurinë ashtu edhe për dizajnin e pastër të API-t.
ArSyeja më kritike është parandalimi i rrjedhjes së të dhënave sensitive — kthimi i drejtpërdrejtë i entiteteve të bazës së të dhënave mund të ekspozojë hash të fjalëkalimeve, fusha të brendshme, token ose të dhëna të tjera që nuk duhet të arrijnë nëklient, një cenueshmëri e zakonshme dhe serioze.
ClassSerializerInterceptor i NestJS me dekoratorët e class-transformer (@Exclude, @Expose, @Transform) ofron një mënyrë të pastër, deklarative për të formuar përgjigjet — duke hequr automatikisht fushat e përjashtuara, riemërtuar dhe transformuar vlerat.
Komprensioni i kësaj është dijeni thelbësore e përditshme për çdo API që kthen të dhëna përdoruesi ose domeni, dhe njohja e gotcha-s kryesore — se serializimi funksionon vetëm në instanca klase, jo në objekte të thjesht (një burim i shpeshtë i bugeve "pse poashtu paraqitet fjalëkalimi?") — është praktikisht e rëndësishme.
Egalisht e vlefshme është njohja e modelit alternativ të DTO-ve të dedikuar të përgjigjeve (hartëzimi i entiteteve në klasa eksplicite të daljes që përmbajnë vetëm fusha të sigurta për klient), e cila ndanë kontratën e API-t nga modeli i bazës së të dhënave dhe është qasja më e sigurt për të dhënat sensitive.
Kontrollimi i duhur i serializimit është një shenjë dalluese e API-ve të sigurta, të dizajnuara mirë NestJS dhe një çështje shpesh e rëndësishme në aplikacione reale që menaxhojnë ndonjë të dhënë jo-publike.