Why controllers handle incoming requests in NestJS - Why It Works This Way

Overview - Why controllers handle incoming requests

What is it?

In NestJS, controllers are special classes that listen for incoming requests from users or other systems. They decide what to do with these requests, like fetching data or saving information. Controllers act as the middlemen between the outside world and the internal parts of the application. They organize how the app responds to different types of requests.

Why it matters

Without controllers, the app wouldn't know how to handle requests or send back useful responses. Imagine a restaurant without waiters; customers wouldn't get their orders taken or food served. Controllers solve this by managing communication, making apps interactive and user-friendly. They keep the app organized and make it easier to add new features or fix problems.

Where it fits

Before learning about controllers, you should understand basic JavaScript/TypeScript and how web servers work. After mastering controllers, you can learn about services that handle business logic and modules that organize the app structure. Controllers are a key step in building full-featured NestJS applications.

Mental Model

Core Idea

Controllers are the gatekeepers that receive, interpret, and respond to incoming requests in a NestJS app.

Think of it like...

Controllers are like receptionists in an office who greet visitors, understand their needs, and direct them to the right department.

┌───────────────┐
│ Incoming HTTP │
│   Request     │
└──────┬────────┘
       │
┌──────▼────────┐
│  Controller   │
│ (Handles and  │
│  routes the   │
│  request)     │
└──────┬────────┘
       │
┌──────▼────────┐
│   Service     │
│ (Business    │
│  logic)       │
└──────┬────────┘
       │
┌──────▼────────┐
│   Response    │
│   Sent Back   │
└───────────────┘

Build-Up - 6 Steps

1

Foundation

What is a Controller in NestJS

Concept: Introduce the basic role of a controller as a class that handles incoming requests.

In NestJS, a controller is a class decorated with @Controller(). It listens for HTTP requests on specific routes and methods like GET or POST. For example, a controller can listen for GET requests at '/users' and return a list of users.

Result

You understand that controllers are the entry points for requests in a NestJS app.

Understanding that controllers are the first stop for requests helps you see how apps organize user interactions.

2

Foundation

Basic Controller Setup and Routing

Concept: Show how to create a simple controller and define routes using decorators.

A controller uses decorators like @Get(), @Post() to define which HTTP methods and paths it handles. For example: import { Controller, Get } from '@nestjs/common'; @Controller('cats') export class CatsController { @Get() findAll() { return 'This returns all cats'; } } This listens for GET requests at '/cats' and returns a string.

Result

You can create a controller that responds to specific HTTP requests.

Knowing how decorators map routes to methods lets you control app behavior clearly and simply.

3

Intermediate

Controllers as Request-Response Managers

🤔Before reading on: Do you think controllers should contain all business logic or just manage requests? Commit to your answer.

Concept: Explain that controllers handle requests but delegate business logic to services.

Controllers receive requests and extract data like parameters or body content. They then call services to perform tasks like database queries. Finally, controllers send back responses. This separation keeps code clean and easier to maintain.

Result

You see controllers as managers that organize request handling without doing heavy work themselves.

Understanding this separation prevents messy code and helps build scalable applications.

4

Intermediate

Handling Different Request Types and Parameters

🤔Before reading on: Can controllers handle query strings, URL parameters, and request bodies all at once? Commit to yes or no.

Concept: Show how controllers extract different parts of requests using decorators.

NestJS provides decorators like @Param(), @Query(), and @Body() to get data from requests. For example: @Get(':id') getCat(@Param('id') id: string) { return `Cat with id ${id}`; } @Post() createCat(@Body() catData) { return `Created cat named ${catData.name}`; } This lets controllers handle complex inputs easily.

Result

You can write controllers that respond to various request details.

Knowing how to extract request data lets you build flexible and interactive APIs.

5

Advanced

Controllers and Middleware Interaction

🤔Before reading on: Do you think middleware runs before or after controllers? Commit to your answer.

Concept: Explain how middleware processes requests before controllers handle them.

Middleware functions run before controllers and can modify requests or responses. For example, middleware can check authentication or log requests. Controllers then receive the processed request. This layering helps keep concerns separated and code organized.

Result

You understand the flow of requests through middleware to controllers.

Knowing middleware runs first helps you design secure and maintainable apps.

6

Expert

How Controllers Enable Dependency Injection

🤔Before reading on: Do you think controllers create their own dependencies or receive them? Commit to your answer.

Concept: Show how NestJS injects services into controllers automatically.

Controllers declare dependencies like services in their constructor. NestJS automatically provides these instances using dependency injection. For example: constructor(private readonly catsService: CatsService) {} This means controllers don't create services themselves but get ready-to-use instances, improving testability and modularity.

Result

You see controllers as parts of a larger system where dependencies are managed automatically.

Understanding dependency injection in controllers unlocks powerful design patterns and easier testing.

Under the Hood

When a request arrives, NestJS matches the URL and HTTP method to a controller method using metadata from decorators. It creates an instance of the controller (or uses an existing one), injects required services, and calls the method with extracted parameters. The method's return value is then serialized and sent as the HTTP response.

Why designed this way?

This design separates concerns clearly: controllers handle routing and request management, services handle business logic. Using decorators and dependency injection makes code declarative and testable. Alternatives like putting all logic in controllers or using manual wiring were harder to maintain and test.

Incoming Request
     │
     ▼
┌───────────────┐
│ Router Layer  │
│ (Matches URL) │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Controller    │
│ (Method call) │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Service Layer │
│ (Business     │
│  logic)       │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Response sent │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do controllers contain all the app's business logic? Commit yes or no.

Common Belief: Controllers should contain all the logic to handle requests and data processing.

Reality: Controllers should only manage requests and delegate business logic to services.

Why it matters: Putting all logic in controllers leads to messy, hard-to-maintain code and makes testing difficult.

Quick: Do controllers create their own service instances? Commit yes or no.

Common Belief: Controllers create new instances of services themselves inside their methods.

Reality: NestJS injects service instances into controllers automatically via dependency injection.

Why it matters: Manually creating services breaks modularity and makes testing and scaling harder.

Quick: Can middleware replace controllers entirely? Commit yes or no.

Common Belief: Middleware can handle all request processing, so controllers are optional.

Reality: Middleware only preprocesses requests; controllers are needed to handle routing and responses.

Why it matters: Relying on middleware alone leads to unclear app structure and harder maintenance.

Quick: Do controllers handle requests synchronously only? Commit yes or no.

Common Belief: Controllers must handle requests synchronously and cannot use async operations.

Reality: Controllers can and often do handle requests asynchronously using async/await.

Why it matters: Not using async in controllers limits app performance and ability to handle real-world tasks like database calls.

Expert Zone

1

Controllers can be scoped as singleton or request-scoped, affecting lifecycle and dependency behavior.

2

Using interceptors with controllers allows modifying requests and responses transparently.

3

Controllers can handle exceptions locally or delegate to global filters for cleaner error management.

When NOT to use

Controllers are not suitable for heavy business logic or data access; use services instead. For simple static content, consider middleware or static serving. For complex workflows, use guards, interceptors, and pipes alongside controllers.

Production Patterns

In production, controllers are kept thin, delegating to services. They use decorators for validation and guards for security. Controllers are organized by feature modules for scalability. Dependency injection enables easy mocking in tests.

Connections

Model-View-Controller (MVC) Pattern

Controllers in NestJS implement the 'Controller' part of MVC.

Understanding MVC helps grasp why controllers separate request handling from data (Model) and UI (View).

Dependency Injection

Controllers receive services via dependency injection.

Knowing dependency injection clarifies how controllers get their dependencies without manual creation.

Receptionist Role in Business

Controllers act like receptionists managing incoming requests and directing them.

Seeing controllers as receptionists helps understand their role as organized entry points.

Common Pitfalls

#1 Putting business logic directly inside controller methods.

Wrong approach:

@Get()
findAll() {
// directly querying database here
return this.database.query('SELECT * FROM users');
}

Correct approach:

@Get()
findAll() {
return this.usersService.findAll();
}

Root cause:

Misunderstanding the separation of concerns between controllers and services.

#2 Manually creating service instances inside controllers.

Wrong approach:

constructor() {
this.usersService = new UsersService();
}

Correct approach:

constructor(private readonly usersService: UsersService) {}

Root cause:

Not using NestJS dependency injection system.

#3 Trying to handle authentication logic inside controllers instead of middleware or guards.

Wrong approach:

@Get()
findAll() {
if (!this.isAuthenticated()) {
throw new UnauthorizedException();
}
return this.usersService.findAll();
}

Correct approach:

Use AuthGuard middleware to protect routes, keeping controllers clean.

Root cause:

Not leveraging NestJS middleware and guards for cross-cutting concerns.

Key Takeaways

Controllers in NestJS are the organized entry points that handle incoming requests and send responses.

They should focus on managing requests and delegate business logic to services for clean code.

Decorators map HTTP methods and routes to controller methods, making routing clear and simple.

Dependency injection provides controllers with ready-to-use services, improving modularity and testing.

Understanding controllers' role helps build scalable, maintainable, and testable NestJS applications.