FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 04 Dependency Injection and the Application Graph
Dependency Injection and the Application Graph How Nest creates and wires controllers, services and modules
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 Dependency Injection and the Application Graph
Dependency injection is object wiring The phrase dependency injection can sound abstract, but the practical question is simple: when HealthController needs HealthService, who creates the service instance and gives it to the controller? In Nest, the IoC container performs that wiring based on the providers registered in modules.
declares dependency @Injectable provider
constructor type metadata
creates + wires instances
Figure - Dependency injection: the controller asks for a service; Nest resolves and supplies the registered provider.
Constructor injection health.controller.ts - the consumer @Controller('health') export class HealthController { constructor(private readonly healthService: HealthService) {} }
health.service.ts - the provider
@Injectable()
export class HealthService {
getStatus() {
return { status: 'ok' };
}
}health.module.ts - the registration @Module({ controllers: [HealthController], providers: [HealthService], }) export class HealthModule {}
These three snippets form one relationship: consumer, dependency, registration. If any side is missing, Nest cannot complete the graph.
What Nest resolves at startup 1 Read AppModule and all imported modules. 2 Collect controller/provider metadata. 3 Create provider instances according to their registration and scope. 4 Inspect constructor dependencies and resolve each required provider. 5 Instantiate controllers with their dependencies already supplied. 6 Fail startup if the graph cannot be resolved.
FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 04 Dependency Injection and the Application Graph
Providers are generally singleton-scoped by default for the application lifecycle. Request scope exists, but using it everywhere would increase complexity and overhead. This phase stays with the default scope.
Classic failure: Nest cannot resolve dependencies Representative startup error Nest can't resolve dependencies of the HealthController (?). Please make sure that the argument HealthService ... is av
Do not reinstall Nest. Read the dependency graph. Is HealthService decorated with @Injectable()? Is it listed in providers? Is it exported/imported if consumed across module boundaries? Is the constructor asking for a runtime-resolvable class/token?
Interfaces are erased at runtime TypeScript interfaces do not exist after compilation. Nest cannot inject an interface by type alone. Later, when we need abstraction tokens, we will use explicit injection tokens. Do not introduce tokens early merely to imitate enterprise architecture.
Program.cs / host bootstrap main.ts + NestFactory Application startup and server bootstrap
Service registered in DI Provider / @Injectable() Reusable application dependency
IServiceCollection / DI Nest IoC container Creates and wires dependencies container
Feature area / registration Module Groups and exposes related capabilities
Attribute routing Decorators such as @Controller and Maps HTTP requests to handlers @Get
Kestrel / host server Fastify through platform adapter Underlying HTTP server implementation
If you know ASP.NET Core DI, the mental model transfers well: constructor injection remains constructor injection. Nest modules supply composition metadata where ASP.NET commonly uses IServiceCollection registration during startup.
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 “Dependency Injection and Application Graph” 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 “Dependency Injection and Application Graph” to a different TaskFlow resource or input. Write the acceptance criteria first, implement it, and provide the evidence that each criterion is satisfied.
Add configuration through Nest Config rather than reading process.env everywhere.
Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.Business logic embedded in decorators/controllers
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.