Frontend – Backend – Database – API

Level: L6 — AI Coding & Vibe Coding (Bài 3/12)

Ranh giới phạm vi đã KHÓA theo phê duyệt tường minh của chủ dự án

Bài 55 (L6, bài này) sở hữu	Bài 65 tương lai (L7) sẽ sở hữu
Mô hình kiến trúc Frontend/Backend/Database/API	Kiến thức API chuyên sâu
Vai trò của API trong 1 hệ thống phần mềm	Endpoint, request/response chi tiết
Đủ hiểu biết API để xây dự án Level 6	HTTP methods (GET/POST/PUT/DELETE…)
—	Headers, parameters, Authentication, tài liệu API

Bài 55 không dạy các mục ở cột phải — khi Level 7 được lập kế hoạch, bài 65 sẽ dẫn chiếu bài 55 làm nền tảng, không dạy lại kiến trúc tổng thể.

1. Mục tiêu học tập

Sau bài này, bạn có thể:

• Vẽ được sơ đồ 4 lớp của 1 sản phẩm phần mềm điển hình: Frontend, Backend, Database, API.
• Giải thích đúng vai trò của từng lớp bằng ngôn ngữ không kỹ thuật.
• Hiểu chu trình Request-Response cơ bản (client hỏi → server trả lời).
• Có đủ vốn từ để đọc hiểu 1 coding agent đang mô tả nó đang sửa “phần frontend” hay “phần backend” của dự án.

2. Khái niệm cốt lõi

Mô hình Client-Server là nền tảng của hầu hết phần mềm hiện đại chạy trên web: “Client gửi request → Server gửi response” [S93]. Client là thiết bị/phần mềm bạn dùng để truy cập (trình duyệt); Server là máy tính lưu trữ và xử lý, gửi dữ liệu về khi được yêu cầu [S93].

4 lớp kiến trúc (mô hình tối thiểu cần có trước khi chạm code):

1. Frontend — phần bạn nhìn thấy và tương tác trực tiếp (giao diện, nút bấm, biểu mẫu). Chạy trên thiết bị của người dùng (trong trình duyệt).
2. Backend — phần xử lý logic phía sau: kiểm tra dữ liệu hợp lệ, quyết định phải làm gì, giao tiếp với database. Người dùng không nhìn thấy trực tiếp lớp này.
3. Database — nơi lưu trữ dữ liệu lâu dài (danh sách ghi chú, tài khoản người dùng) — dữ liệu vẫn còn đó dù bạn tắt máy/đóng trình duyệt.
4. API — “đường dây” kết nối các lớp lại với nhau, theo 1 “ngôn ngữ” chung để Frontend hỏi Backend, hoặc để hệ thống của bạn hỏi 1 dịch vụ bên ngoài (ví dụ: 1 dịch vụ AI tóm tắt văn bản).

Chu trình HTTP cơ bản (4 bước, theo đúng cơ chế thật của web) [S93]:

1. Trình duyệt tra địa chỉ server (DNS lookup).
2. Trình duyệt gửi request (yêu cầu) tới server.
3. Server xử lý và gửi lại response (kết quả) — kèm 1 mã trạng thái (ví dụ “200 OK” nghĩa là thành công).
4. Trình duyệt ráp dữ liệu nhận được thành giao diện hiển thị cho bạn.

3. Tại sao nội dung này quan trọng

Khi bạn giao việc cho coding agent (“thêm 1 nút lưu ghi chú”), việc đó thực chất chạm vào cả 4 lớp (nút bấm ở Frontend → gọi API → Backend xử lý → lưu vào Database). Nếu không có mô hình 4 lớp này trong đầu, bạn sẽ khó hiểu vì sao “1 yêu cầu đơn giản” đôi khi cần AI sửa nhiều file ở nhiều nơi khác nhau, và khó debug khi có lỗi (không biết lỗi nằm ở lớp nào).

4. Cơ chế hoạt động

Ví dụ cụ thể — nút “Lưu ghi chú” hoạt động qua 4 lớp thế nào:

1. Bạn bấm nút “Lưu” (Frontend).
2. Frontend gửi 1 request qua API tới Backend, kèm nội dung ghi chú.
3. Backend nhận request, kiểm tra hợp lệ (ghi chú không được để trống), rồi ra lệnh lưu.
4. Database lưu ghi chú đó lại.
5. Backend gửi response báo “đã lưu thành công” qua API về lại Frontend.
6. Frontend hiển thị thông báo “Đã lưu!” cho bạn thấy.

Phân định AI vs con người:

	Điều bạn cần hiểu	Điều AI có thể thực hiện	Điều bạn phải xác nhận
Kiến trúc 4 lớp	Mỗi lớp làm nhiệm vụ gì, vì sao tách riêng	Viết code cho cả 4 lớp	Tính năng có thực sự chạy đúng cả chu trình, không chỉ 1 lớp
API	API là “đường dây” giữa các lớp, không phải phép màu	Tự thiết kế/gọi API nội bộ dự án	Dữ liệu đi qua API có đúng như mong đợi (không bắt buộc hiểu chi tiết kỹ thuật — đó là bài 65 tương lai)
Database	Dữ liệu cần “có chỗ lưu lâu dài”	Tự thiết kế cấu trúc lưu trữ	Dữ liệu quan trọng có thực sự được lưu lại, không bị mất khi tắt/mở lại ứng dụng

5. Mental model

Coi 1 sản phẩm phần mềm như 1 nhà hàng: Frontend là khu vực khách ngồi và thực đơn (những gì khách nhìn thấy, tương tác); Backend là nhà bếp (nơi xử lý, chuẩn bị, không ai nhìn thấy trực tiếp); Database là kho nguyên liệu (nơi lưu trữ mọi thứ lâu dài); API là người phục vụ — mang yêu cầu (order) từ khách vào bếp, và mang kết quả (món ăn) từ bếp ra lại cho khách, theo 1 “quy trình” cố định mà cả 2 bên (khách và bếp) đều hiểu.

6. Hướng dẫn từng bước

1. Chọn 1 ứng dụng bạn dùng hàng ngày (1 app ghi chú, mạng xã hội).
2. Với mỗi hành động bạn thực hiện trên app đó (đăng bài, thích, bình luận), thử “vẽ” ra 4 lớp: cái gì bạn nhìn thấy (Frontend)? cái gì chắc chắn phải xử lý phía sau (Backend)? dữ liệu gì cần lưu lại (Database)?
3. Đọc lại chu trình HTTP 4 bước và đối chiếu với hành động vừa chọn — request là gì, response là gì trong tình huống đó?
4. Nhờ 1 coding agent giải thích lại cấu trúc 1 dự án mẫu (nếu có sẵn) theo đúng 4 lớp này — kiểm tra bạn có hiểu đúng lời giải thích không.

7. Ví dụ thực tế

Áp dụng cho dự án tích lũy Level 6 (Trợ Lý Ghi Chú Cá Nhân Có AI Tóm Tắt): Frontend = màn hình nhập/xem ghi chú; Backend = xử lý logic (kiểm tra ghi chú hợp lệ, gọi dịch vụ AI để tóm tắt khi cần); Database = nơi lưu toàn bộ ghi chú của bạn; API = 2 đường dây — 1 nối Frontend với Backend (nội bộ), 1 nối Backend với 1 dịch vụ AI bên ngoài (để lấy bản tóm tắt). Đây chính là bức tranh kiến trúc bạn sẽ dùng lại xuyên suốt các bài sau của Level 6.

8. Prompt/template/workflow

Tính năng: ___
Frontend (người dùng nhìn/thao tác gì?): ___
Backend (logic gì cần xử lý phía sau?): ___
Database (dữ liệu gì cần lưu lại?): ___
API (frontend và backend "nói chuyện" với nhau như thế nào?): ___

Giải thích cấu trúc dự án này theo đúng 4 lớp: phần nào là Frontend, phần
nào là Backend, dữ liệu được lưu ở đâu (Database), và Frontend/Backend
giao tiếp với nhau qua API như thế nào.

9. Visual hoặc diagram cần thiết

Hình 6.3 — 4 lớp kiến trúc: Frontend → API → Backend → Database, với request đi 1 hướng và response quay lại. [S93]

10. Bài tập thực hành

1. Áp dụng khung “vẽ kiến trúc 4 lớp” (mục 8) cho ý tưởng ứng dụng ghi chú cá nhân của riêng bạn (có thể khác đôi chút với ví dụ mục 7).
2. Với mỗi lớp, viết 1 câu mô tả cụ thể (không dùng thuật ngữ kỹ thuật) nhiệm vụ của lớp đó trong ứng dụng của bạn.
3. Thử giải thích lại toàn bộ mô hình 4 lớp cho 1 người khác (không cần biết code) — nếu họ hiểu được, bạn đã nắm vững mô hình.

11. Checklist

Đặt lại checklist

• Vẽ được đúng 4 lớp kiến trúc cho 1 tính năng cụ thể.
• Giải thích được vai trò từng lớp bằng ngôn ngữ không kỹ thuật.
• Hiểu chu trình Request-Response cơ bản.
• Biết API là 'đường dây kết nối', không cần biết chi tiết kỹ thuật (endpoint, method, header — dành cho bài 65 tương lai).

12. Lỗi thường gặp

• Nhầm Frontend là “toàn bộ ứng dụng” — quên rằng phần lớn logic quan trọng (và rủi ro bảo mật) nằm ở Backend, nơi người dùng không nhìn thấy.
• Nghĩ dữ liệu “tự động được lưu” — không hiểu vai trò riêng của Database, dẫn tới bất ngờ khi dữ liệu biến mất nếu Backend không thực sự lưu vào Database.
• Cố học sâu chi tiết kỹ thuật API ngay ở bài này — không cần thiết, đây là bài mô hình tổng quan, chi tiết API học ở L7 bài 65 (tương lai).

13. Giới hạn & khi nào KHÔNG nên áp dụng

• Không dạy chi tiết kỹ thuật API (endpoint, HTTP method, header, authentication, tài liệu API) — đây là ranh giới đã khóa, thuộc phạm vi L7 bài 65 tương lai.
• Không dạy cách chọn công nghệ cụ thể cho từng lớp (framework Frontend nào, database nào) — đó là quyết định thực hành sẽ xuất hiện tự nhiên khi coding agent đề xuất ở các bài sau.
• Mô hình 4 lớp là đơn giản hóa có chủ đích cho người mới — hệ thống thật có thể phức tạp hơn (nhiều backend, nhiều database, cache…), không cần biết ở giai đoạn này.

14. An toàn & quản trị (Safety/Governance)

Hiểu đúng Backend là nơi “người dùng không nhìn thấy trực tiếp” giúp bạn nhận ra: mọi kiểm tra bảo mật quan trọng phải nằm ở Backend, không chỉ ở Frontend — vì Frontend chạy trên máy người dùng, có thể bị can thiệp/bỏ qua. Đây là nền tảng tư duy quan trọng cho bài 62 (Security) sau này.

15. Best practices

1. Luôn “vẽ” 4 lớp trước khi yêu cầu coding agent xây 1 tính năng mới — giúp bạn giao yêu cầu rõ ràng hơn và dễ kiểm tra kết quả hơn.
2. Khi AI báo “đã sửa xong”, hỏi lại nó đã đụng tới lớp nào — luyện thói quen giám sát có cấu trúc.
3. Giữ đúng ranh giới đã học — không cố hiểu sâu kỹ thuật API ngay bây giờ, việc đó sẽ tự nhiên rõ ràng hơn khi thực hành ở các bài sau.

16. Nội dung nâng cao (không bắt buộc)

Mô hình 4 lớp ở bài này là nền tảng xuyên suốt toàn bộ hành trình còn lại của Level 6 — từ bài 56 (Vibe Coding) trở đi, mọi lần bạn giao việc cho coding agent, hãy tự hỏi “việc này chạm tới lớp nào trong 4 lớp đã học?” Đây cũng là mô hình sẽ được đào sâu hơn (riêng phần API) khi Level 7 tới lượt lập kế hoạch.

17. Nguồn tham khảo

[S93] How the Web Works, MDN Web Docs (Mozilla) — mô hình client-server, chu trình HTTP request-response, giao thức nền tảng · Dẫn chiếu (không trích dẫn mới): Level 7 bài 65 tương lai (API chuyên sâu, ranh giới đã khóa).

18. Ngày kiểm chứng

Claim kỹ thuật kiểm chứng qua nguồn Tier 1 (S93) ngày 2026-07-12. Mô hình kiến trúc 4 lớp là kiến thức phổ quát, ổn định — rủi ro lỗi thời thấp.