FS26
Ctrl K
Phase 06 · Lesson 02

API URLs and Environment Boundaries

≈ 2 min core reading · 500 source/companion words
Learning contract

What you should be able to do after this

  • Explain API URLs and Environment Boundaries without relying on framework buzzwords.
  • Connect the lesson to the phase outcome: Connect Next.js and NestJS through an explicit, debuggable HTTP boundary with environment-safe base URLs and correct CORS behavior.
  • Reproduce the relevant behavior and verify it with evidence.
  • Diagnose at least one representative failure instead of guessing.
Figure 6.2 — TaskFlow boundary map
Next.js component/action
API client
HTTP request
CORS/origin rules
NestJS
HTTP response
UI state
This lesson belongs to Phase 06. Keep the full request/data path visible even when today's code changes only one box.
Instructor workflow: predict first → implement the smallest slice → run it → inspect evidence → break one assumption → diagnose → explain it back. Do not copy the whole code block before understanding the first failing boundary.

FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 06 API URLs and Environment Boundaries

VOLUME 02 - FRONTEND + BACKEND FOUNDATIONS

API URLs and Environment Boundaries Configuration, NEXT_PUBLIC_ and protecting server-only values

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 2 of Phase 06

FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 06 API URLs and Environment Boundaries

URLs are configuration, not component content During local development, Next.js listens on port 3000 and NestJS on port 4000. It is tempting to paste http://localhost:4000 into every component. That works for ten minutes and becomes painful as soon as staging or production exists. We introduce the smallest useful configuration boundary now.

apps/web/.env.local .env.local - local file, do not commit

Code
API_BASE_URL=http://127.0.0.1:4000
NEXT_PUBLIC_API_BASE_URL=http://127.0.0.1:4000

apps/web/.env.example .env.example - safe contract, commit this

Code
API_BASE_URL=
NEXT_PUBLIC_API_BASE_URL=

Why two variables? Variable Available where? Purpose

API_BASE_URL Server runtime only Server Components and server-only code

NEXT_PUBLIC_API_BASE_URL Browser bundle + server Browser/client code that must know the public API URL

Next.js only exposes environment values to browser code when they are explicitly prefixed with NEXT_PUBLIC_. Those public values are inlined into browser JavaScript at build time, so they must never contain secrets.

SECURITY BOUNDARY

A value being called an environment variable does not make it secret. NEXT_PUBLIC_* means the value is intentionally public to the browser. API URLs are normally fine; database passwords and service-role keys are not.

Environment variable location When a Next.js project uses a src/ directory, environment files still belong at the project root, such as apps/web/.env.local, not inside apps/web/src.

Normalize one development hostname Use either localhost consistently or 127.0.0.1 consistently while learning. Browsers treat origin as scheme + host + port. http://localhost:3000 and http://127.0.0.1:3000 are different origins even though both reach the same machine. Our Nest CORS example allows both to reduce accidental local friction, but consistency remains a good habit.

Fail early when required configuration is absent Server-side example

Code
const apiBaseUrl = process.env.API_BASE_URL;

if (!apiBaseUrl) { throw new Error('API_BASE_URL is not configured'); }

FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 06 API URLs and Environment Boundaries

REAL-WORLD NOTE

Later deployments may use different internal and public API addresses. Keeping the server and browser configuration concepts separate now prepares the architecture for that difference without adding deployment complexity yet.

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.

Executable lesson studio · communication

Now turn the explanation into engineering skill.

API URLs and Environment Boundaries matters because it changes a real boundary in TaskFlow. The goal is to understand the inputs, owner, observable output, and failure modes before adding more abstraction.

By the end, you should be able to

  • Explain API URLs and Environment Boundaries in terms of concrete inputs, ownership, outputs, and evidence.
  • Implement or reproduce the smallest TaskFlow slice that demonstrates this communication concept.
  • Diagnose one representative communication failure using observable evidence instead of trial-and-error.
Figure 6.2B — Mental model
Next.js UI
typed request
NestJS endpoint
service
response state
Read left-to-right while implementing. When debugging, walk right-to-left until the first observed fact differs from your prediction.
Code-along sequence

One coherent change at a time

  1. 01

    Restate the goal of “API URLs and Environment Boundaries” as one observable behavior. Write the success signal before touching code.

  2. 02

    Trace the boundary map: Next.js UI → typed request → NestJS endpoint → service → response state. Mark the one boundary this lesson changes.

  3. 03

    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.

  4. 04

    Implement the smallest vertical slice. Add one coherent change, run the narrowest verification command, and read the output before continuing.

  5. 05

    Connect the slice to TaskFlow’s phase artifact: A typed API client boundary that can call the NestJS health/tasks endpoints from the appropriate Next.js execution context.. Verify behavior from the outside as a user or API client would.

  6. 06

    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.

  7. 07

    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.

txtBoundary trace
Input -> owner -> transformation -> observable output -> failure evidence

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.

Verification

Prove the happy path

  1. Run the narrowest relevant command or request and require a clean exit/status.
  2. Inspect the boundary-specific evidence: terminal output, Network panel, database row/query plan, test report, container health, or deployment logs.
  3. Repeat the behavior once after the change so a one-off cached or stale result cannot masquerade as success.
Break it on purpose

Build debugging memory

  1. Wildcard CORS with credentials
  2. Change one assumption in the communication example—identity, input, configuration, ordering, connectivity, or state—and predict the exact symptom before running it.
SymptomInvestigation path
Expected result does not appear

Return to the nearest observable boundary: input, network, process log, database, or rendered UI. Compare actual evidence with the predicted path.

A shortcut appears to fix it

Change one variable at a time and reproduce the original failure after the fix; otherwise you have correlation, not diagnosis.

Closed-reference challenge

Can you transfer the idea?

Without copying the final source, create a second small scenario that applies “API URLs and Environment Boundaries” to a different TaskFlow resource or input. Write the acceptance criteria first, implement it, and provide the evidence that each criterion is satisfied.

Explain-back

Answer these without reopening the solution

  1. What problem does API URLs and Environment Boundaries solve in TaskFlow, and what would be observably wrong without it?
  2. Which part of the communication boundary owns the decision, and which neighboring layer must not own it?
  3. What evidence proves the happy path instead of merely suggesting it worked?
  4. Name one realistic failure or abuse case and the first place you would inspect.
  5. If requirements doubled tomorrow, which part of this design should stay stable and which part is allowed to change?
Lesson studio

Turn the reading into skill

01

Do it

Call a public endpoint from a Server Component and inspect where the request originates.

Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.
02

Break it safely

Wildcard CORS with credentials

Predict the symptom before causing the failure. Then locate the earliest boundary where reality diverges from expectation.
03

Explain it back

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.
Exit ticket

Before marking complete

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.

← From Two Apps to One SystemServer Side Fetch with Next.js →