Controllers handle incoming HTTP requests and return responses. They are decorated with @Controller('route-prefix') and their methods use HTTP-method decorators like @Get(), @Post(), etc. Controllers are thin — they delegate business logic to providers/services.
A controller is responsible for handling incoming requests and returning responses to the client. It should remain thin and delegate actual business logic to services.
Map routes to handler methods using decorators.
Extract data from the request (params, query, body, headers).
Delegate logic to services.
Return the response (NestJS handles serialization automatically).
We need a new endpoint /users that returns a list of users; walk me through how you would create the controller and what its responsibilities are.
A request hits a route defined in a controller but the response body is always empty; what might be missing in the controller method?
How would you use decorators in a controller to extract query parameters and pass them to a service?
Our controller calls several services and sometimes returns a 500 error; how would you structure error handling and status code mapping inside the controller?
During a review you see a controller directly accessing the database; why is that a problem and how would you refactor it?
If you need to protect all routes in a controller with authentication, what options do you have and what trade‑offs do they involve?
Our API gateway forwards requests to multiple NestJS microservices; how would you design controllers to keep latency low and avoid coupling business logic to the controller layer?
When scaling to thousands of concurrent requests, what considerations around async handling, interceptors, or pipes become critical in controller design?
We need to version our API without duplicating controller code; how would you approach versioning at the controller level while keeping the codebase maintainable?
We are migrating a large legacy Express codebase to NestJS; how would you plan the transition of routing logic and controllers to minimize disruption across teams?
Different teams have written controllers with varying patterns; what governance or architectural guidelines would you establish to standardize controller responsibilities and promote reuse?
If we want to expose both REST and GraphQL endpoints for the same business operations, how would you structure controllers (or their equivalents) to avoid duplication and keep contracts clear?