⚙️ Dành cho người làm app bằng vibe coding

Backend là gì và vì sao app nào cũng cần?

Khi dùng AI để tạo app, phần nhìn thấy (frontend) thường xong rất nhanh. Nhưng để app nhớ được dữ liệu, cho người dùng đăng nhập và chạy thật cho nhiều người, bạn cần backend. Trang này giúp bạn hiểu backend vừa đủ để chỉ huy AI đúng hướng và chọn đúng công cụ.

Luật bỏ túi: Frontend là mặt tiền. Backend là hậu trường lo dữ liệu, đăng nhập và xử lý. Hiểu backend là bớt phụ thuộc vào may rủi khi nhờ AI.
Giao diện app của bạn Frontend
↓   gọi qua API   ↑
Backend - hậu trường
🗄️DatabaseLưu dữ liệu
🔐AuthĐăng nhập
🛰️FunctionsXử lý
Khái niệm gốc

Hai cách để có backend

Người dùng chỉ thấy giao diện. Phía sau, backend lưu dữ liệu, kiểm tra ai được làm gì và xử lý logic. Bạn có hai con đường để có nó.

🧱 Tự dựng server

Bạn tự lo mọi thứ từ đầu.

  • Tự thuê máy chủ, cài database, viết phần đăng nhập.
  • Tự lo bảo mật, sao lưu, cập nhật.
  • Linh hoạt và mạnh nhất, nhưng tốn công và cần kỹ thuật.
Hợp với bài toán lớn, có đội kỹ thuật.

🧰 Dùng BaaS (Backend-as-a-Service)

Thuê một dịch vụ đã gói sẵn.

  • Có sẵn database, đăng nhập, lưu file, hàm xử lý.
  • Cắm vào là chạy, hợp với người làm vibe coding.
  • Đổi lại bạn theo quy ước của dịch vụ đó.
Hợp với hầu hết người mới và app vừa.
Ẩn dụ dễ nhớ: Tự dựng server giống như tự xây nhà kho rồi tự kéo điện nước, tự thuê bảo vệ. BaaS giống như thuê một kho có sẵn điện nước và bảo vệ, bạn chỉ việc bỏ hàng vào và dùng.
Từ điển

Thuật ngữ backend cốt lõi

Không cần học sâu ngay. Chỉ cần hiểu đúng vai trò để gọi tên được thứ mình muốn AI làm.

🧰

BaaS

Backend đóng gói sẵn. Một dịch vụ gộp database, đăng nhập, lưu file và hàm xử lý vào một chỗ.

Ví dụ: Supabase, Firebase, Appwrite.
🔌

API

Cửa giao tiếp. Frontend gọi backend qua API để lấy hoặc gửi dữ liệu.

Như gọi món qua ô cửa phục vụ.
✏️

CRUD

4 việc với dữ liệu. Create (tạo), Read (đọc), Update (sửa), Delete (xóa). Gần như mọi app chỉ xoay quanh 4 việc này.

Thêm, xem, sửa, xóa một mục.
🗃️

SQL vs NoSQL

Hai kiểu lưu dữ liệu. SQL là bảng hàng cột có quan hệ chặt. NoSQL là tài liệu linh hoạt dạng JSON.

Supabase dùng SQL, Firebase dùng NoSQL.

Realtime

Tự cập nhật ngay. Dữ liệu mới hiện ra cho mọi người mà không cần tải lại trang.

Hợp với chat, bảng cộng tác.
📁

Storage

Nơi lưu file. Dành cho ảnh, video, tài liệu. Khác với database vốn lưu chữ và số.

Ảnh đại diện, file đính kèm.
🛰️

Serverless / Edge Function

Code chạy mà không phải quản máy chủ. "Edge" là chạy ở nơi gần người dùng cho nhanh.

Gửi email, gọi AI, xử lý riêng.
🔐

Authentication

Xác thực danh tính. Backend biết người đang dùng là ai trước khi cho thao tác.

Xem chi tiết ở phần Đăng nhập.
Hiểu để không bất ngờ hóa đơn

Vì sao backend lại tính tiền?

Hầu hết dịch vụ cho dùng miễn phí tới một mức, vượt mức thì trả thêm. Đây là những "đồng hồ đo" quyết định chi phí. Con số cụ thể đổi theo thời gian, nên xem trực tiếp trên trang của dịch vụ.

Database sizedữ liệu đã lưu
Egressdữ liệu gửi ra
MAUngười dùng trong tháng

Hình minh họa, không phải số thật.

🗄️

Database size

Tổng dung lượng dữ liệu chữ và số bạn lưu. Càng nhiều bản ghi càng lớn.

📤

Egress (Bandwidth)

Lượng dữ liệu app gửi ra cho người dùng. App đông người xem nhiều thì egress cao.

👥

MAU

Monthly Active Users: số người dùng có hoạt động trong tháng, thường tính qua đăng nhập.

🪪

Third-Party Users

Monthly Active Third-Party Users: người đăng nhập qua nhà cung cấp bên ngoài, được đếm và tính riêng.

📁

Storage

Dung lượng file ảnh, video. Tính tách riêng với database.

🛰️

Số lần gọi function

Mỗi lần edge function chạy đều được đếm. Chạy càng nhiều càng tốn.

Ý chính: Backend tính theo kiểu dùng bao nhiêu trả bấy nhiêu. Lúc học và làm thử gần như miễn phí. Chỉ khi app có đông người dùng thật, chi phí mới đáng để tính kỹ.
Phần quan trọng nhất

Chọn backend nào cho app của bạn?

Không có backend "tốt nhất", chỉ có backend hợp với bài toán. Đây là cách định hướng nhanh, từ dễ tới khó.

🗂️ SQL - dữ liệu quan hệ

Dữ liệu có cấu trúc rõ, nhiều bảng liên kết nhau (người dùng, nhóm, đơn hàng, quyền). Truy vấn phức tạp dễ dàng.

Supabase (Postgres), Neon, PlanetScale

🧩 NoSQL - dữ liệu linh hoạt

Dữ liệu hay đổi hình dạng, cần ghi nhanh và realtime. Thường hợp với app mobile.

Firebase (Firestore), MongoDB
Phổ backend theo quy mô bài toán
Nhỏ, nhanhCực lớn, phức tạp
1

Học & làm thử

Mục tiêu là có app chạy nhanh nhất có thể.

PocketbaseSupabaseFirebase
2

App thật, vừa

Vài trăm tới vài chục nghìn người. Cần đủ database + đăng nhập + lưu file.

SupabaseFirebaseAppwrite
3

Database mạnh

Khi truy vấn phức tạp và dữ liệu quan hệ là trọng tâm.

SupabaseNeonPlanetScale
4

Cực lớn / riêng

Quy mô doanh nghiệp, yêu cầu đặc biệt, cần đội kỹ thuật.

AWSGoogle CloudAzure
Bảng quyết định nhanh: nếu... thì chọn...
Nếu bạn mới học và muốn nhanh có cả database lẫn đăng nhập.
→ BaaS như Supabase hoặc Firebase
Nếu dữ liệu có nhiều quan hệ (người dùng, nhóm, công việc, quyền).
→ Nền SQL như Supabase
Nếu bạn làm app mobile realtime, đã quen hệ Google.
→ Firebase
Nếu bạn muốn mã nguồn mở, tự host, kiểm soát dữ liệu.
→ Supabase, Appwrite, Pocketbase
Nếu bạn chủ yếu cần một database mạnh để cắm vào.
→ Neon hoặc PlanetScale
Nếu app cực lớn, yêu cầu đặc biệt, có đội kỹ thuật.
→ Tự dựng trên AWS / GCP / Azure
🚀

Gợi ý cho người làm vibe coding

Supabase là điểm bắt đầu rất hợp: có sẵn database SQL, đăng nhập, lưu file, realtime và function; mã nguồn mở; tài liệu tốt và AI cũng rất "rành" Supabase nên hỗ trợ bạn tốt. Bắt đầu ở đây, sau này đổi vẫn kịp.

Cho người dùng vào app

Đăng nhập thế nào?

Hầu hết BaaS lo sẵn phần này. Bạn chỉ cần bật cách phù hợp và hiểu hai khái niệm dễ nhầm bên dưới.

Authentication = bạn là ai

Xác thực danh tính: kiểm tra đúng người trước khi cho vào.

Authorization = bạn được làm gì

Phân quyền: ai được xem, sửa, xóa cái gì sau khi đã đăng nhập.

📧

Email + mật khẩu

Quen thuộc với mọi người. Cần xử lý quên mật khẩu và xác minh email.

Magic link

Gửi một đường link vào email, bấm là vào. Không phải nhớ mật khẩu.

🔗

Đăng nhập mạng xã hội

Bấm "Tiếp tục với Google / GitHub". Nhanh, không phải tạo mật khẩu mới. Đây là OAuth.

📱

OTP điện thoại

Gửi mã số qua SMS. Hợp với app cần số điện thoại thật.

Phần con người phải canh

Bảo mật khi nhờ AI làm backend

AI viết code rất nhanh, nhưng bảo mật là chỗ dễ sai nhất. Đây là những điều cần nhớ khi vibe coding với backend.

🛡️

RLS - khóa dữ liệu theo người

Row Level Security: mỗi người chỉ đọc và sửa dữ liệu của mình. Không bật RLS thì bất kỳ ai cũng có thể lấy sạch dữ liệu. Đây là việc bắt buộc.

🔑

Hai loại khóa

Khóa công khai (anon key) có thể để ở frontend vì đã bị RLS giới hạn. Khóa bí mật (service key) mở mọi cửa, tuyệt đối không để lộ.

🧳

Giấu secret đúng chỗ

Để khóa bí mật trong environment variable. Thêm file .env vào .gitignore để không vô tình đẩy lên GitHub.

🤖

Đừng đưa secret cho AI

Không dán khóa bí mật hay mật khẩu database vào prompt. Sau khi AI viết xong, kiểm tra xem có khóa nào bị ghi thẳng vào code công khai không.

Đừng tin frontend

Luôn kiểm tra quyền ở backend. Người xấu có thể gọi thẳng API mà không qua giao diện đẹp của bạn.

⚙️

Bật xác minh & giới hạn

Bật xác minh email, giới hạn số lần gọi, và chỉ mở đúng quyền thật sự cần. Mặc định nên đóng, mở dần khi cần.

Ghép mọi thứ lại

Khi người dùng bấm "Lưu", chuyện gì xảy ra?

Đây là luồng có backend thật, để bạn thấy các phần ăn khớp với nhau ra sao.

Người dùng thao tác

Bấm một nút trên giao diện, ví dụ thêm hoặc lưu một mục.

Gửi qua API

Frontend gửi yêu cầu kèm dữ liệu tới backend.

Kiểm tra quyền

Backend hỏi: đã đăng nhập chưa, RLS có cho phép không?

Ghi vào database

Nếu hợp lệ, dữ liệu được lưu lại an toàn.

Cập nhật màn hình

Kết quả hiện ra. Nếu có realtime, người khác cũng thấy ngay.

Backend không phải hộp đen đáng sợ. Nó là hậu trường hoàn toàn có thể hiểu được.

Khi bạn nắm được database, đăng nhập, chi phí và bảo mật, bạn không còn "nhờ AI làm backend" một cách mơ hồ. Bạn biết chọn đúng công cụ, giao việc rõ ràng và giữ dữ liệu người dùng an toàn.

Phong Ho - AI Business