Official NestJS documentation on controllers, covering response handling strategies, query parameter parsing, route handler return types, state management, and DTO best practices.
Key takeaways
- Library-specific response handling: Use
@Res()decorator to inject the native Express/Fastify response object for full control over headers, status codes, and cookies. Thepassthrough: trueoption allows mixing manual response manipulation with Nest’s standard handling. - Complex query parsing: For nested objects or arrays in query strings (e.g.,
?filter[where][name]=John), configure the HTTP adapter’s query parser—Express usesextendedmode, Fastify requires a customquerystringParserwith theqslibrary. - Observable return types: Route handlers can return RxJS Observables; Nest subscribes automatically and resolves the final emitted value.
- State sharing model: Nearly everything is shared across requests in Nest (database pools, singleton services). This is safe because Node.js doesn’t use a multi-threaded request model.
- DTOs should be classes: Use classes instead of interfaces for DTOs so they remain as runtime entities. This enables Pipes to access metatype information for validation.
Entities and concepts
- @Res() Decorator - Library-specific response object injection
- Passthrough Mode - Hybrid response handling with
@Res({ passthrough: true }) - Complex Query Parsing - Handling nested and array query parameters
- Observable Return Types - RxJS Observable support in route handlers
- State Sharing Model - Singleton-based request handling in NestJS
- DTO Classes vs Interfaces - Runtime metatype access for validation
- Pipes - Validation and transformation features requiring runtime types
Connections to existing knowledge
These clippings complement the existing NestJS entity by documenting core controller patterns beyond basic routing. The State Sharing Model explains why singleton services (like the ioredis client in Redis Repository Pattern) are safe in NestJS applications.