Clean API Client Boundary

FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 06 A Clean API Client Boundary

VOLUME 02 - FRONTEND + BACKEND FOUNDATIONS

A Clean API Client Boundary Centralize transport details without premature abstractions

Phase 06 turns two working applications into one full-stack system.

Browser Next.js NestJS API

http://localhost:3000 apps/web http://localhost:4000

HTTP fetch

Later phases replace in-memory Todos with Prisma + PostgreSQL.

Figure - TaskFlow Phase 06 architecture. The browser sees Next.js on port 3000 while the independent NestJS API listens on port 4000.

Book 6 of Phase 06

FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 06 A Clean API Client Boundary

The first useful frontend boundary: a tiny API client After the first successful fetch, a common mistake is to copy URLs, headers, response.ok checks and JSON parsing into every page. We now have a concrete duplication problem, so a small HTTP-client module has earned its place.

Page / Client Component asks for Todos

lib/api/todos.ts HTTP contract in one place

fetch() Request + Response

NestJS /todos resource API

Figure - A small API-client module prevents URLs and HTTP parsing logic from spreading across UI components. It is not yet a repository abstraction.

What belongs in lib/api/todos.ts ● The Todo response type used by this phase. ● URL construction relative to a supplied base URL. ● HTTP method and headers. ● JSON serialization/deserialization. ● response.ok checks and useful HTTP error messages.

What does not belong there yet ● React state or JSX. ● TanStack Query configuration. ● Repository interfaces. ● MobX stores. ● Prisma or database code. ● Authentication tokens before auth exists. apps/web/src/lib/api/todos.ts - phase-end shape

FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 06 A Clean API Client Boundary

export interface Todo { id: number; title: string; completed: boolean; }

async function expectJson<T>(response: Response): Promise<T> { if (!response.ok) { throw new Error(`HTTP ${response.status} for ${response.url}`); } return response.json() as Promise<T>; }

export async function fetchTodos(baseUrl: string) {
return expectJson<Todo[]>(await fetch(`${baseUrl}/todos`, { cache: 'no-store' }));
}

export async function createTodo(baseUrl: string, title: string) { return expectJson<Todo>(await fetch(`${baseUrl}/todos`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ title }), })); }

Why pass baseUrl instead of reading process.env inside the helper? The same pure HTTP helper can run in a Server Component with API_BASE_URL and in a Client Component with NEXT_PUBLIC_API_BASE_URL. If the helper itself imported a server-only variable, it would become unsafe to reuse from client code. Passing configuration makes the execution boundary explicit.

NOT A REPOSITORY YET

This module is a small transport helper. It does not pretend HTTP is interchangeable with memory/database implementations, and it does not introduce interfaces merely for architecture style. Repository Pattern arrives only after the course has a concrete reason for it.

Official source notes Primary framework references: Next.js App Router Fetching Data and fetch API documentation; Next.js Environment Variables documentation; NestJS CORS documentation. Browser protocol references: MDN CORS, preflight request, and Fetch API documentation.

The course remains version-locked to the versions established in Phase 00. These sources are used to verify concepts and current API behavior, not to silently upgrade the course midstream.