一個請求是怎麼流動的

現在我們把它們串起來。我們來跟著使用者點選 "儲存資料"，走過你剛剛認識的每一個部件。這是全書最有用的一個心智模型；如果你只內化一張圖，就讓它是這張。

1. 使用者 點選 "儲存資料"
        │
        ▼
2. FRONTEND（HTML 表單，JavaScript 讀取這些值）
        │   發出一個 HTTP 請求：  "POST /profile  { name: 'Ada' }"
        ▼
3. HOSTING 把請求路由到你正在執行的 BACKEND
        │
        ▼
4. BACKEND
     ├─ 這個使用者登入了嗎？            (沒有 → 響應 401，停止)
     ├─ 資料有效嗎？                  (無效 → 響應 400，停止)
     └─ 都沒問題 → 儲存到 DATABASE
        │
        ▼
5. DATABASE 寫入這一行，向 BACKEND 確認回執
        │
        ▼
6. BACKEND 響應：  "200 OK  { saved: true }"
        │
        ▼
7. FRONTEND 收到響應，更新 DOM
        │   ("資料已儲存 ✓") —— 使用者看到了它
        ▼
   完成

把每一層做了什麼走一遍：frontend 收集了輸入並把它發出去；託管 把請求送到了正確的地方；backend 執行了規則（登入、校驗）並做了決定；資料庫 把它變成永久的；然後響應一路流回來，好讓 frontend 能更新螢幕。每一個應用都是這個迴圈的各種變體，每秒鐘跑成千上萬次。

注意那些檢查全都發生在 backend，從不發生在 frontend——這就是第一節裡那條規則的實際運用：frontend 是給使用者的，backend 是給真相的。當你知道每一步發生在哪裡時，你就能精確地描述一個功能（"儲存之前在 backend 上校驗郵箱"），而不是含糊地說（"把表單弄好"）——而精確，就是整場遊戲的全部。