FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 04 Create the TaskFlow NestJS API
Create the TaskFlow NestJS API Safe monorepo scaffolding and the first backend checkpoint
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 Create the TaskFlow NestJS API
Step 1 - Confirm the monorepo before scaffolding Run scaffolding commands from the TaskFlow repository root. This matters because the existing pnpm workspace should own dependency installation and the root Git repository should remain the only repository. From: taskflow\ Get-Location node -v pnpm -v git status
The working directory is the TaskFlow root, Node uses the Phase 00/01 locked LTS line, pnpm works, and Git reports the existing repository rather than a new empty repository.
Step 2 - Scaffold the NestJS application Use a temporary Nest CLI invocation instead of requiring a permanently global CLI. The CLI is a project-generation tool; the framework packages themselves will live inside apps/api. From: taskflow\ pnpm dlx @nestjs/cli@12.0.3 new apps/api --package-manager pnpm --skip-git --no-observe
--skip-git prevents the generated application from creating a nested .git directory. --no-observe answers the current CLI observability prompt explicitly, keeping the course setup deterministic. The package-manager flag keeps installation aligned with the workspace.
Why use pnpm dlx?
pnpm dlx downloads and runs the CLI command without requiring a global Nest CLI installation. The generated project still records its own framework dependencies in apps/api/package.json.
Expected structure after scaffolding taskflow/ |-- apps/ | |-- web/ | `-- api/ | |-- src/ | | |-- app.controller.ts | | |-- app.module.ts | | |-- app.service.ts | | `-- main.ts | |-- package.json | |-- nest-cli.json | `-- tsconfig.json |-- packages/ |-- package.json |-- pnpm-lock.yaml `-- pnpm-workspace.yaml
Step 3 - Prove the generated API works before changing its HTTP platform From: taskflow\ cd apps/api pnpm run start:dev
The first run is deliberately boring. It establishes a checkpoint: Nest can compile and start before we introduce Fastify. If Fastify setup later fails, we can compare the failure against this known-good state.
FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 04 Create the TaskFlow NestJS API
The API starts successfully. Keep this result in mind; it is your baseline before replacing the default Express platform adapter.
Understand the generated files before deleting anything File Responsibility
src/main.ts Process entry point and Nest application bootstrap.
src/app.module.ts Root module; tells Nest what belongs to the application graph.
src/app.controller.ts Initial HTTP route boundary generated by the CLI.
src/app.service.ts Initial injectable provider used by the controller.
nest-cli.json Nest CLI/compiler project configuration.
package.json API scripts and dependencies owned by apps/api.
The generated controller/service are useful teaching material. We will first understand their relationship, then replace the starter route with a Health feature. Deleting unfamiliar code before understanding it removes a learning opportunity.
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 “Create the TaskFlow NestJS API” 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 “Create the TaskFlow NestJS API” 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.Provider not registered/exported/imported correctly
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.