Một yêu cầu di chuyển như thế nào
Giờ hãy ghép mọi thứ lại với nhau. Hãy theo dõi người dùng của chúng ta bấm "Lưu hồ sơ" đi qua từng phần bạn vừa gặp. Đây là mô hình tư duy hữu ích nhất trong toàn bộ cuốn sách; nếu bạn chỉ khắc ghi một sơ đồ, hãy chọn cái này.
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
Hãy đi qua từng bước xem mỗi lớp đã làm gì: thu thập dữ liệu nhập vào và gửi đi; hosting đưa yêu cầu tới đúng nơi; thực thi các quy tắc (đăng nhập, xác thực) và ra quyết định; làm cho nó trở nên vĩnh viễn; và phản hồi chảy ngược trở lại toàn bộ chặng đường để frontend có thể cập nhật màn hình. Mọi ứng dụng đều là biến thể của vòng lặp này, chạy hàng nghìn lần mỗi giây.
Hãy để ý rằng mọi kiểm tra đều diễn ra ở backend, không bao giờ ở frontend — quy tắc từ phần đầu tiên, đang được áp dụng: frontend dành cho người dùng, backend dành cho sự thật. Khi bạn biết ở đâu mỗi bước xảy ra, bạn có thể mô tả một tính năng một cách chính xác ("xác thực email ở backend trước khi lưu") thay vì mơ hồ ("làm cho biểu mẫu hoạt động") — và chính xác là toàn bộ ván bài.