How a request flows

Now we tie it together. Let's follow our user clicking "Save profile" through every piece you just met. This is the single most useful mental model in the book; if you internalize one diagram, make it this one.

1. USER clicks "Save profile"
        │
        ▼
2. FRONTEND (HTML form, JavaScript reads the values)
        │   sends an HTTP request:  "POST /profile  { name: 'Ada' }"
        ▼
3. HOSTING routes the request to your running BACKEND
        │
        ▼
4. BACKEND
     ├─ is this user logged in?        (no  → respond 401, stop)
     ├─ is the data valid?             (no  → respond 400, stop)
     └─ all good → save to the DATABASE
        │
        ▼
5. DATABASE writes the row, confirms back to the BACKEND
        │
        ▼
6. BACKEND responds:  "200 OK  { saved: true }"
        │
        ▼
7. FRONTEND receives the response, updates the DOM
        │   ("Profile saved ✓") — the user sees it
        ▼
   DONE

Walk through what each layer did: the frontend gathered input and sent it; hosting got the request to the right place; the backend enforced the rules (login, validation) and decided; the database made it permanent; and the response flowed all the way back so the frontend could update the screen. Every app is variations on this loop, run thousands of times a second.

Notice the checks all happen in the backend, never the frontend — the rule from the first section, in action: the frontend is for the user, the backend is for the truth. When you know where each step happens, you can describe a feature precisely ("validate the email on the backend before saving") instead of vaguely ("make the form work") — and precise is the entire game.