FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 04 Modules, Controllers and Providers
Modules, Controllers and Providers The basic structural vocabulary of a Nest application
Next.js NestJS + Fastify separate applications apps/web - already built apps/api - this phase
renders TaskFlow UI
Figure - Phase 04 keeps frontend and backend independent. They will communicate later in Phase 06.
FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 04 Modules, Controllers and Providers
The three core responsibilities Concept Responsibility Question it answers
Module Composition / boundary Which related controllers and providers belong together?
Controller HTTP boundary Which request path and method should call which handler?
Provider / Service Reusable application behavior What work should happen after the HTTP boundary delegates?
root composition
health feature boundary not built yet
Figure - Nest module graph: the root module composes feature modules; each feature groups closely related controllers and providers.
Read AppModule first
apps/api/src/app.module.ts - starter concept
import { Module } from '@nestjs/common';
import { AppController } from './app.controller.js';
import { AppService } from './app.service.js';@Module({ imports: [], controllers: [AppController], providers: [AppService], }) export class AppModule {}
The decorator is not decoration in the visual sense. It carries metadata that Nest reads while building the application graph. The controller and service do not become available merely because their files exist; the module registers them into the graph.
Controller responsibility Conceptual starter controller @Controller() export class AppController { constructor(private readonly appService: AppService) {}
@Get()
getHello() {
return this.appService.getHello();
}
}FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 04 Modules, Controllers and Providers
The controller knows HTTP: route mapping and request handling. It delegates the actual response-producing behavior to a provider. This distinction becomes more valuable once business rules are non-trivial.
Provider responsibility Conceptual starter provider @Injectable() export class AppService { getHello() { return 'Hello World!'; } }
A provider is a class managed by the Nest dependency injection container. Services are common providers, but providers can also represent repositories, factories, clients or other reusable dependencies later in the course.
Why feature modules matter A large backend should not place every controller and provider in AppModule. Feature modules group a cohesive capability such as Health, Todos, Users or Projects. AppModule then becomes composition rather than a dumping ground.
Create a module when a group of controllers/providers belongs to one capability and should be composed as a unit. Do not create one module per file, and do not create speculative Core/Common modules before a concrete responsibility exists.
Build HealthModule
From: taskflow\apps\api
pnpm exec nest generate module health
pnpm exec nest generate controller health --no-spec
pnpm exec nest generate service health --no-specThe generators are not magic either. They create files and update module metadata. Always review the diff so you understand what changed. From: taskflow\ git diff -- apps/api
You can identify the root module, a feature module, an HTTP controller and an injectable service, and you can explain why they are separate responsibilities.
Official source notes This phase is written against NestJS 12.0.3 and the Nest CLI 12.0.3 release line. Fastify remains on the stable v5 line; the September 17, 2026 stable patch reference is 5.12.5. The course does not adopt Fastify 6 alpha builds.
Primary references: docs.nestjs.com/modules, docs.nestjs.com/providers, docs.nestjs.com/techniques/performance, github.com/nestjs/nest/releases, github.com/nestjs/nest-cli/releases, github.com/fastify/fastify/releases.
NestJS structure becomes valuable when the request pipeline and responsibility of controllers, services, guards, pipes, and providers are explicit rather than magical.
Restate the goal of “Modules Controllers and Providers” as one observable behavior. Write the success signal before touching code.
Trace the boundary map: HTTP request → Fastify adapter → Nest pipeline → controller → service → response. Mark the one boundary this lesson changes.
Inspect the current repository state and record the exact files, route, table, or runtime involved. Avoid creating an abstraction before you can name the existing owner.
Implement the smallest vertical slice. Add one coherent change, run the narrowest verification command, and read the output before continuing.
Connect the slice to TaskFlow’s phase artifact: A modular API with health endpoint and a small feature module whose controller and service responsibilities are separate.. Verify behavior from the outside as a user or API client would.
Create one controlled failure that is safe to reproduce. Predict the symptom first, capture evidence, locate the earliest broken boundary, then fix only that cause.
Close the reference and rebuild or explain the core change from memory. Record what you would monitor or test before trusting the same change in production.
@Controller("tasks")
export class TasksController {
constructor(private readonly tasks: TasksService) {}
@Get()
findAll() {
return this.tasks.findAll();
}
}Do not copy this as a finished answer. Predict what each boundary does, type the smallest useful slice, run it, then compare the result with your prediction.
Read the constructor index in the error, then check provider registration, module imports, and exports in that order.
Confirm method/path, controller registration, global prefix, and guard/pipe behavior using request logs.
Without copying the final source, create a second small scenario that applies “Modules Controllers and Providers” to a different TaskFlow resource or input. Write the acceptance criteria first, implement it, and provide the evidence that each criterion is satisfied.
Inject the service through the constructor and explain how Nest resolves it.
Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.Huge AppModule containing unrelated features
Predict the symptom before causing the failure. Then locate the earliest boundary where reality diverges from expectation.Why does this responsibility live here, what input does it trust, what output proves success, and what would go wrong if another layer owned it?
If your explanation is vague, repeat the boundary trace before moving on.Close the reference. Reproduce the core idea from memory or explain the exact request/data flow aloud. Then check your diff or notes for accidental shortcuts that bypass validation, authorization, error handling, or verification earned in earlier phases.