How Modern Full- Stack Applications Work A visual mental model for browsers, frontend rendering, APIs, business logic, persistence, authentication and state ownership.
Book 1 · Full-stack mental model Course baseline: September 17, 2026 · Windows-first · Project-driven · Production-oriented
Contents 1. A request is a journey 7. The API boundary
Phase 00 | Page 2 of 10
A request is a journey through responsibilities When a user clicks Create Task, no single framework “does the feature.” Multiple layers cooperate. Becoming a full-stack developer means understanding that journey well enough to diagnose it when something goes wrong.
Figure 1 - Core application request path - This is the central diagram we will repeatedly expand throughout the course.
The browser renders HTML and CSS, runs client-side JavaScript, stores limited client state, sends network requests, receives responses, enforces web security rules such as CORS, and reports failures in developer tools. It does not decide authoritative business rules just because it can run code.
Next.js is the presentation application. It owns routes, pages, layouts, rendering choices, UI composition, navigation and interaction. Later it also coordinates client-side server state through TanStack Query. The course deliberately prevents Next.js from becoming a second backend full of duplicated business rules.
Phase 00 | Page 3 of 10
HTTP is the contract boundary between independently running applications. A request carries a method, URL, headers and optional body. A response carries a status code, headers and optional body. This boundary is valuable because the frontend and backend can evolve independently as long as they honor the contract.
Method Path Headers Body POST /tasks Auth, Content-Type JSON
Figure 2 - HTTP request anatomy - The API boundary is explicit; it is not a function call disguised as networking.
NestJS provides the application architecture for controllers, providers, dependency injection, guards, interceptors and modules. Fastify is the HTTP platform underneath NestJS in this course. Controllers translate HTTP into application calls; services own business behavior.
Phase 00 | Page 4 of 10
Figure 3 - Backend responsibility chain - Keep controllers thin enough that business rules remain reusable and testable.
If you know ASP.NET Core: a Nest controller is conceptually similar to a controller, providers/ services use dependency injection, guards/interceptors overlap with filter/middleware concerns, and PrismaService loosely occupies the “database access gateway” role that DbContext often plays. The mapping is useful, but the frameworks are not identical.
Prisma is not PostgreSQL. It is the application-facing ORM/data-access layer. It turns model definitions into typed database operations and manages schema changes through migrations. In our architecture, Prisma stays behind NestJS so browser code never receives database credentials.
PostgreSQL is authoritative persistent storage for application data: users, memberships, projects, tasks, comments, audit history and other relational records. Supabase hosts PostgreSQL for the course, but the relational concepts remain standard PostgreSQL concepts.
Phase 00 | Page 5 of 10
Authentication answers “who are you?” Authorization answers “are you allowed to perform this action on this resource?” Those questions happen at different points and should remain conceptually separate.
Figure 4 - Future authentication flow - Authentication establishes a trustworthy identity before business logic evaluates permissions.
Phase 00 | Page 6 of 10
Allowed?
Figure 5 - Authorization decision - A valid identity is necessary but not sufficient; permissions and resource ownership still matter.
Many frontend applications become difficult because every kind of state is placed in one global store. The course teaches state by ownership instead.
TanStack Query Local / URL / Form state tasks · projects · users · API results dialogs · filters · inputs · navigation
PostgreSQL Services / optional stores authoritative business data rules and interaction logic
Figure 6 - State ownership map - Different categories of state deserve different tools and lifecycles.
Phase 00 | Page 7 of 10
A professional mental model includes failure. Network requests time out. Validation rejects input. Authentication expires. Authorization denies access. Database constraints conflict. Bugs throw exceptions. The goal is not to pretend failures are rare; the goal is to know which layer should detect, translate, log and present them.
Database Prisma Service HTTP constraint error decision 409
UI message “Already exists”
Figure 7 - Failure translation - Errors should become more meaningful as they travel toward the user.
Phase 00 | Page 8 of 10
Figure 8 - Complete vertical slice - This is the mental model you should be able to narrate from memory by the end of Phase 00.
1. Why should Next.js not receive a PostgreSQL password? 2. What responsibility would be lost if all business logic lived in controllers? 3. What is the difference between authentication and authorization?
Phase 00 | Page 9 of 10
4. Where does durable business data live? 5. Why is HTTP useful even when frontend and backend are in one monorepo? 6. Give one example of server state and one example of local UI state.
You can narrate the request path without memorizing framework slogans: user → UI → HTTP → controller → service → Prisma → PostgreSQL → response → UI.
Phase 00 | Page 10 of 10
Full Stack Mental Model 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.
Restate the goal of “Full Stack Mental Model” as one observable behavior. Write the success signal before touching code.
Trace the boundary map: User intent → UI boundary → API contract → business rule → persistence → observable result. 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 one-page architecture map plus an ADR-style note describing the responsibilities of Next.js, NestJS, Prisma, PostgreSQL/Supabase, and supporting infrastructure.. 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.
Input -> owner -> transformation -> observable output -> failure evidenceDo 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.
Return to the nearest observable boundary: input, network, process log, database, or rendered UI. Compare actual evidence with the predicted path.
Change one variable at a time and reproduce the original failure after the fix; otherwise you have correlation, not diagnosis.
Without copying the final source, create a second small scenario that applies “Full Stack Mental Model” to a different TaskFlow resource or input. Write the acceptance criteria first, implement it, and provide the evidence that each criterion is satisfied.
Draw TaskFlow as boxes and arrows before opening an IDE.
Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.Putting business rules in React components
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.