Your idea feels like one thing, but every web app is made of a few standard parts, each with a separate job. If you cannot name those parts, you cannot tell your agent which one to change, and you cannot reason about why something broke. This chapter gives you that map: the five pieces and how a single click travels through them.
The five pieces1.3.1
Every web app is built from the same handful of parts. Learn these names once and the rest of the handbook stops sounding foreign.
| Piece | What it does |
|---|---|
| Frontend | What the user sees and clicks in the browser: the pages, buttons, forms |
| Backend | The server that runs your logic: it decides what happens when a request arrives |
| Database | Where data is stored so it survives after the browser closes |
| API | The agreed set of messages the frontend and backend use to talk to each other |
| Hosting | The computers where all of the above actually run, reachable over the internet |
Frontend and backend are two different programs1.3.2
The frontend runs on the user's device, inside their browser. The backend runs somewhere else, on a server you control, out of the user's reach.
This split matters because anything secret (passwords, private data, business rules) lives in the backend, never the frontend. The frontend is public by nature: anyone can open it and look.
The API is a contract, not a place1.3.3
The frontend cannot reach into the database directly. It sends a request to the backend through the API, a fixed list of allowed messages like "give me this user's orders" or "save this comment."
Think of the API as a menu. The frontend can only order dishes on the menu, and the backend decides how each one is cooked.
The database remembers, hosting runs it1.3.4
The database is the app's memory. Close the browser, restart the server, and whatever was saved there is still waiting.
Hosting is simply the rented computers where the frontend, backend, and database live so the public can reach them. Which specific tools fill each slot is a later decision, covered when you choose your stack.
Trace one click through all five1.3.5
Example: A user clicks "Save" on a comment. The frontend packages the text and sends it over the API to the backend. The backend checks the user is allowed, then writes the comment to the database. The database confirms, the backend replies through the API, and the frontend shows the new comment on screen. All of it runs on hosting.
Every feature you build is some version of this loop. Once you can see the loop, a bug stops being "the app is broken" and becomes "which piece dropped the message."
Do this now: take one feature from your must-have list and write the round trip in one sentence, naming all five pieces, the way the example above does.
