FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 04 Bootstrap and the Fastify Adapter
Bootstrap and the Fastify Adapter How main.ts turns modules into a listening HTTP 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 Bootstrap and the Fastify Adapter
NestJS and Fastify solve different problems Layer What it contributes
NestJS Modules, dependency injection, controllers, providers, guards, pipes, interceptors and application structure.
Fastify The concrete HTTP server/runtime that accepts requests and sends responses.
@nestjs/platform-fastify The adapter that lets Nest run on Fastify while keeping Nest abstractions.main.ts application entry point
NestFactory.create(...) starts Nest runtime
FastifyAdapter selects HTTP platform
AppModule root dependency graph
listen(4000) opens local HTTP port
Figure - Bootstrap flow: main.ts chooses the platform, provides the root module, then starts listening.
Step 1 - Install the Nest Fastify platform adapter From: taskflow\apps\api pnpm add @nestjs/platform-fastify@12.0.3 pnpm remove @nestjs/platform-express
The course chooses Fastify intentionally, so keeping the Express platform package after the migration would create ambiguity. Nest remains the application framework; only the concrete HTTP platform changes.
The course is locked to Fastify 5.x. The September 17, 2026 stable patch reference is 5.12.5. Fastify 6 is still an alpha line and is not used in this course.
Step 2 - Change main.ts
apps/api/src/main.ts
import { NestFactory } from '@nestjs/core';
import {
FastifyAdapter,
NestFastifyApplication,
} from '@nestjs/platform-fastify';
import { AppModule } from './app.module.js';async function bootstrap() {FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 04 Bootstrap and the Fastify Adapter
const app = await NestFactory.create<NestFastifyApplication>( AppModule, new FastifyAdapter(), );
const port = Number(process.env.PORT ?? 4000);
await app.listen(port, '127.0.0.1');
}void bootstrap();
Read the file as an architectural sentence ● NestFactory.create starts the Nest runtime. ● AppModule is the root of the dependency graph. ● FastifyAdapter selects Fastify as the HTTP platform implementation. ● NestFastifyApplication gives TypeScript the correct application type for this platform. ● listen opens the local port only after Nest has created and wired the application graph.
Why port 4000?
The frontend already uses the common Next.js development port 3000. The backend uses 4000 so both applications can run simultaneously without fighting for the same port.
Step 3 - Verify the Fastify-backed API From: taskflow\apps\api pnpm run start:dev
Open the generated root route or use Invoke-WebRequest. The exact starter response matters less than the architectural checkpoint: Nest is now running on Fastify and listening at localhost:4000. In a second PowerShell window (Invoke-WebRequest -Uri 'http://127.0.0.1:4000/' -UseBasicParsing).Content
NestJS boots successfully using Fastify, and an HTTP request reaches the generated controller.
Fastify-specific caution Once Fastify is the platform, recipes that depend directly on Express request/response objects or Express-only middleware may not apply. Prefer Nest abstractions first; when platform-specific behavior is necessary, use the Fastify equivalent deliberately.
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 “Bootstrap and Fastify Adapter” 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 “Bootstrap and Fastify Adapter” to a different TaskFlow resource or input. Write the acceptance criteria first, implement it, and provide the evidence that each criterion is satisfied.
Create a HealthModule with controller and service instead of putting everything in AppController.
Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.Adapter-specific plugins assumed to work like Express middleware
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.