Bài viết

Vibe Code

Frontend, Backend, Database, API: giải thích dễ hiểu cho Vibe Coder

Từ một trang HTML đến chức năng bình luận: hiểu Frontend, Backend, Database và API qua một câu chuyện dễ hình dung.

02/10/2026 · 8 phút đọc · Lê Huy Thái

Bên dưới nút Gửi bình luận có gì?
  • Frontend nhận thao tác và hiển thị kết quả trên trình duyệt.
  • Backend kiểm tra, xử lý yêu cầu và làm việc với Database để lưu dữ liệu dùng chung.
  • API quy định cách các phần mềm giao tiếp với nhau.

Hôm nay mình sẽ giải thích cực kỳ dễ hiểu về Frontend, Backend, Database, API, ... chúng nó là gì? Cho các bạn mới hoặc vibe code tay ngang hiểu hơn nhé

Website chỉ để vào đọc

Chuyện kể ngày xưa, người ta làm một website bằng cách viết các trang HTML rồi đặt chúng trên một máy chủ (Server). Người xem gõ địa chỉ website (ví dụ tensorlab.tech) vào trình duyệt trên máy của mình (Client). Cái này tương đương với việc trình duyệt hỏi Server: "Ê, cho tao xem trang tensorlab.tech này". Server gửi file HTML về, trình duyệt đọc và dựng thành trang cho người xem

Điểm cần nhớ là Server đang giữ file, còn trang mà bạn nhìn thấy được thực chất là trình duyệt đã tải file HTML về và dựng trên máy của bạn. Người khác mở cùng website thì máy họ cũng nhận file và dựng một trang của riêng họ. Nếu trang có thêm code để bấm nút, mở menu hay thay đổi thứ gì đó ngay trên màn hình, phần code ấy cũng chạy trong trình duyệt của từng người.

Câu chuyện vẫn đẹp nếu website chỉ để mọi người vào đọc. Nhưng một ngày đẹp trời người ta muốn có chức năng bình luận. Một người gõ "Bài này hay quá", trang trên máy họ hiện thêm dòng bình luận. Thế người khác mở bài viết có thấy không? Không, vì máy người kia đang xem bản trang web của họ. File HTML trên Server vẫn vậy. Người khác vào vẫn chẳng thấy bình luận đâu

Muốn người khác cũng thấy, phải có chỗ chung

Người ta nghĩ: Server là chỗ tất cả mọi người đều tìm đến, người ta đã gửi yêu cầu (Request) để lấy nội dung web, vậy sao không gửi yêu cầu để lưu cái bình luận lại? Thế là người ta viết thêm code chạy trên Server để làm việc đó. Có bình luận mới thì code này nhận, xử lý và lưu lại ở một nơi nào đó. Lần sau ai mở bài viết, Server lấy cả những bình luận đã lưu để gửi cho họ xem

Phần code xử lý công việc phía sau website này được gọi là Backend. Trong câu chuyện này, Server là máy đảm nhiệm việc phục vụ website, còn Backend là chương trình xử lý công việc trên đó. Code trong trình duyệt của mỗi người thì chỉ biết chuyện xảy ra ở trình duyệt ấy; muốn nhiều người cùng nhìn thấy một bình luận, phải gửi nó về chỗ chung để xử lý và lưu lại

Ban đầu, Backend có thể lưu bình luận vào một file. Nhưng website ngày càng nhiều bài, mỗi bài lại có cả đống bình luận. Giờ muốn tìm tất cả bình luận của bài số 50, sửa một bình luận cũ, xóa bình luận vi phạm, vân vân, lại còn nhiều người gửi bình luận cùng lúc nữa. Cứ tự đọc, tìm và ghi lại trong file thì người làm web phải lo ngày càng nhiều chuyện

Thế là người ta dùng một nơi lưu dữ liệu có tổ chức: Database, hay cơ sở dữ liệu. Đi cùng nó là phần mềm quản lý để giúp lưu, tìm, thêm, sửa, xóa dữ liệu và xử lý việc nhiều người cùng truy cập. Các bạn có thể hình dung sơ sơ như một bảng Excel để chứa dữ liệu, nhưng có nhiều khả năng phục vụ ứng dụng hơn

Có dữ liệu rồi, sao phải viết lại từng trang?

Có chỗ lưu dữ liệu rồi, người ta nhìn lại website: mỗi lần thêm một bài viết lại phải tạo thêm một file HTML, trong khi cấu trúc các trang gần như giống nhau, chỉ khác tiêu đề, nội dung, tác giả, ... Chưa kể lúc sửa layout thì phải sửa hàng loạt file. Website có 1.000 bài đúng là cực hình

Vậy sao không lưu nội dung các bài viết vào Database và chỉ làm một mẫu trang bài viết? Khi trình duyệt yêu cầu bài nào, Backend tìm dữ liệu của bài ấy, lắp vào mẫu trang rồi gửi kết quả về. Đây là Website động: nội dung trang được tạo theo dữ liệu cần hiển thị, thay vì lúc nào Server cũng gửi nguyên một file HTML viết sẵn. "Động" ở đây là nội dung có thể thay đổi theo dữ liệu nhé, không phải trang phải có hiệu ứng chuyển động. Mỗi cái khung để lắp data vào có thể gọi là một Template. Một blog có 1.000 bài vẫn có thể dùng chung một Template cho tất cả trang bài viết, cùng một Template khác cho Trang chủ

Quay lại phần người xem đang nhìn và thao tác

Đến đây mình mới quay lại phần mà người xem đang nhìn và thao tác trên trình duyệt. Phần đó gọi là Frontend. Thực ra nó đã có từ trang HTML đầu tiên rồi, chứ không phải đợi có Backend thì Frontend mới ra đời, nhưng không có gì nhiều để nói đến

Về sau, người ta muốn giao diện làm được nhiều việc hơn: nhập bình luận thì thấy kết quả ngay, bấm thích thì số lượt thích thay đổi, kéo xuống thì bài mới hiện ra, đổi ngôn ngữ hay dark theme mà không phải mở một trang khác, ... Phần chạy ở trình duyệt cũng ngày càng nhiều việc. Người ta làm ra các công cụ như React, Angular để xây và quản lý những giao diện phức tạp ấy dễ hơn

Còn Backend thì lo những việc phía Server: nhận yêu cầu từ nhiều người, kiểm tra người dùng có được phép bình luận không, tìm bài viết, lưu dữ liệu, trả kết quả, ... Hai phía làm những việc khác nhau, nên ở các dự án lớn thường sẽ có người tập trung vào Frontend và người tập trung vào Backend.

Nhưng hai phía này phối hợp với nhau kiểu gì? Quay lại cái nút Gửi bình luận: Frontend không thể chỉ nhắn "Ê, lưu hộ tao cái này" rồi mong Backend tự hiểu. Nó phải biết gửi yêu cầu tới đâu, cần gửi nội dung bình luận và bài viết nào. Backend cũng phải thống nhất sẽ trả về cái gì khi lưu thành công, và trả về cái gì nếu có lỗi

Giao diện để phần mềm giao tiếp với nhau theo những quy định đã thống nhất đó gọi là API (Application Programming Interface). Trong ví dụ này, chúng ta đang nói đến Web API giữa Frontend và Backend; API còn được dùng ở nhiều nơi khác nữa.

Hai bên giao tiếp như thế nào?

Ví dụ, muốn thêm bình luận thì Frontend gửi bài viết cần thêm (articleId - id để định danh) và content (nội dung bình luận) theo cách Backend quy định. Frontend không cần biết Backend lưu bình luận vào bảng nào; Backend cũng không cần biết ô nhập bình luận trên màn hình trông ra sao. Hai bên chỉ cần làm đúng cách giao tiếp đã thống nhất. Những cục dữ liệu nhiều ngoặc và dấu nháy kép các bạn hay thấy thường được viết dưới dạng JSON, một kiểu mà API rất hay dùng

Thực ra việc trình duyệt gửi yêu cầu và Server trả lời đã có ngay từ đầu câu chuyện. API cũng không phải thứ chỉ xuất hiện sau khi có hai ông Frontend, Backend ngồi làm riêng. Đến lúc website có nhiều chức năng và hai phía phải trao đổi nhiều loại dữ liệu hơn, việc quy định rõ cách giao tiếp mới trở nên quan trọng hơn

Vậy sau post này, các bạn có thể hình dung bên dưới nút Gửi bình luận của một website cơ bản sẽ diễn ra thế nào chưa?

  1. 01
    Bạn nhập bình luận và bấm Gửi

    Frontend nhận thao tác của bạn.

  2. 02
    Frontend gửi yêu cầu theo API

    Gửi bài viết và nội dung bình luận theo cách Backend quy định.

  3. 03
    Backend kiểm tra

    Kiểm tra người dùng, bài viết và nội dung bình luận.

  4. 04
    Lưu vào Database

    Lưu bình luận để người khác cũng có thể xem.

  5. 05
    Backend trả kết quả

    Trả kết quả cho Frontend.

  6. 06
    Frontend hiển thị

    Hiện bình luận hoặc báo lỗi cho bạn.

Thực tế sẽ phức tạp hơn nhưng cơ bản là vậy

Nếu các bạn thích kiểu nội dung giải thích dễ hiểu này thì nhắn mình để mình viết tiếp 98 bài nữa nhé

Bạn muốn mình giải thích tiếp điều gì?

Gửi mình những thuật ngữ hoặc chỗ bạn còn thấy khó hiểu khi làm web app nhé.