Enable ClassSerializerInterceptor globally so it calls instanceToPlain() on every response. Decorate entity fields with @Exclude() to omit sensitive data and @Expose() for whitelist mode. Controllers must return class instances — returning plain objects bypasses the serialization decorators entirely.
Controllers must return class instances — plain objects have no metadata for the interceptor to read.
@Exclude() — blacklist approach: all properties included by default, decorated ones are stripped.
@Expose() with excludeExtraneousValues: true — whitelist approach: only decorated properties are included.
@SerializeOptions() at route or controller level overrides the global interceptor configuration.
ClassSerializerInterceptor must be registered via APP_INTERCEPTOR for DI support (e.g. injecting Reflector).
We have a simple NestJS controller returning a User entity. How would you use ClassSerializerInterceptor together with @Exclude() and @Expose() to ensure the password field is never sent in the response?
If you add @Expose({ name: 'fullName' }) to a getter in a DTO, what will the JSON output look like when the interceptor is applied?
What happens if you forget to enable the interceptor globally but still use @Exclude() on a property?
You need to return different fields for admin vs regular users from the same endpoint. How could you configure ClassSerializerInterceptor and the decorators to handle this without writing separate DTOs?
During a code review you notice that a nested object is still exposing its internal id even though @Exclude() is on the property. What could cause this and how would you debug it?
We introduced a new optional field in a DTO and want it omitted when undefined. How does ClassSerializerInterceptor treat undefined values with @Expose()? Explain any configuration needed.
Our microservice returns large payloads with many nested objects. Discuss the performance implications of using ClassSerializerInterceptor at scale and any strategies to mitigate overhead.
We are migrating a legacy codebase that manually maps entities to plain objects. How would you design a migration plan to adopt ClassSerializerInterceptor and @Exclude/@Expose across multiple modules while minimizing risk?
When integrating with GraphQL, we need to hide certain fields only for specific roles. How would you extend or customize ClassSerializerInterceptor to support role‑based field exclusion?
At the organization level we want a consistent serialization policy across dozens of services. What architectural guidelines would you set for using ClassSerializerInterceptor, and how would you enforce them across teams?
Consider a scenario where a new compliance requirement mandates that PII fields be redacted in logs but still sent to trusted downstream services. How would you adapt the interceptor or decorators to satisfy this dual requirement without code duplication?
If we need to support versioned APIs where field names change over time, how would you leverage @Expose({ name: ... }) and interceptor configuration to manage multiple versions while keeping a single source of truth?