FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 04 TaskFlow Backend Shell
TaskFlow Backend Shell Consolidate the first professional API structure and map familiar ASP.NET ideas
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 TaskFlow Backend Shell
The Phase 04 backend shell taskflow/ `-- apps/ |-- web/ `-- api/ |-- src/ | |-- health/ | | |-- health.controller.ts | | |-- health.module.ts | | `-- health.service.ts | |-- app.module.ts | `-- main.ts |-- nest-cli.json |-- package.json `-- tsconfig.json
This structure is intentionally small. There is no common/, core/, repositories/, domain/, infrastructure/ or database/ directory yet because none has a concrete responsibility in Phase 04.
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 the whole backend as one sentence main.ts asks Nest to create an application from AppModule using FastifyAdapter. AppModule imports HealthModule. HealthModule registers HealthController and HealthService. A GET request to /health reaches the controller, which delegates to the service, and Nest serializes the returned object to the HTTP response.
FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 04 TaskFlow Backend Shell
If you can say that confidently, you understand Phase 04 architecture. ASP.NET Core NestJS Course interpretation
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
Next.js NestJS + Fastify separate applications localhost:3000 127.0.0.1:4000
renders TaskFlow UI
Figure - End of Phase 04: two processes, two responsibilities, no cross-application request yet.
Why not connect them now?
Because Phase 05 teaches HTTP and REST deliberately. Phase 06 then uses that mental model to connect Next.js to NestJS. Keeping these concerns separate prevents CORS, fetch, routing and backend structure from becoming one confusing setup step.
Professional definition of done ● The API starts with Fastify on port 4000. ● The root AppModule composes HealthModule. ● HealthController owns the HTTP route; HealthService owns the reusable status behavior. ● GET /health returns predictable JSON. ● Generated starter files without responsibilities are removed. ● The root Git repository remains the only Git repository. ● A production build succeeds before the phase is considered complete. From: taskflow\apps\api pnpm run build
FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 04 TaskFlow Backend Shell
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 “TaskFlow Backend Shell and ASPNET Mappings” 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 “TaskFlow Backend Shell and ASPNET Mappings” to a different TaskFlow resource or input. Write the acceptance criteria first, implement it, and provide the evidence that each criterion is satisfied.
Generate the API workspace and replace the default HTTP adapter with Fastify deliberately.
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.