Trong bối cảnh hầu hết developer quen với backend kiểu “app chạy liên tục” (Express/Nest/Fastify…), việc deploy API lên Vercel thường ở vị trí “tò mò nhiều hơn là tự tin”: liệu một nền tảng sinh ra cho frontend có thực sự phù hợp để vận hành backend production?


Khi làm dự án tapi — một headless CMS thuần TypeScript với API riêng — mình có dịp thử nghiên cứu việc đưa backend lên Vercel, và câu chuyện trở nên thú vị.


API không còn là `npm start`: Tư duy lại backend


Vercel nhắc ta một điều cơ bản: API không phải là một ứng dụng chạy liên tục (always-on) — mà là một tập hợp các hàm (functions) được gọi khi cần.


Tư duy “server 24/7 lắng nghe request” nhường chỗ cho mô hình event-driven. Trong tapi, thay vì nghĩ “server chạy Prisma + auth + routing”, ta nhìn thành:

  • Mỗi route là một serverless function
  • Auth trở thành middleware nhẹ
  • Database client phải được tái sử dụng (re-use) thay vì khởi tạo mới cho mỗi request
  • Không có state nội bộ — mọi thứ từ token tới config đều externalized

Cảm giác giống như refactor một app monolith thành mesh của các function nhỏ, nhưng vẫn dùng chung business logic.

Đây là thay đổi mindset hơn là thay đổi công cụ.


Hiệu năng & cold-start: Khổ qua biết nấu thì vẫn ngon.


Vấn đề hay được nhắc đến nhất: cold-start.

React component cold-start nghe dễ chịu — API cold-start thì lại căng hơn, nhất là API auth, CMS hay dashboard như trong tapi. Nhưng thực tế:

  • Phần lớn request admin UI và API của tapi là traffic không cao đột biến → Vercel chưa làm khó.
  • Nếu là hệ real-time trade engine thì câu chuyện khác — nhưng CMS, API CRUD, content-as-a-service?

Khi code được tách đúng, cold-start có thể cảm nhận được nhưng không ảnh hưởng nghiêm trọng đến trải nghiệm.


Database trong thế giới serverless



Điểm buộc phải nghĩ kỹ: connection pooling. Serverless bùng nổ kết nối tới DB nếu không cẩn thận, một sáng thức giấc nhận quả build to đùng


Trong tapi dùng Prisma, nên giải pháp là:

  • prisma client reuse (singleton)
  • Connection pool từ provider DB (Supabase, Neon, PlanetScale…)
  • Tránh query nặng không cần thiết


Serverless ép dev suy nghĩ nghiêm túc về DB layer — điều mà nhiều app monolith bùng nổ sau khi scale vì không chuẩn bị.


Điều mình thích ở sự kết hợp này


✅ Tách biệt môi trường rõ ràng

Dev = chạy local

Prod = function per route

Không bị cảm giác “máy local giả vờ làm production”.

✅ Logs, rollback, deploy tốc độ cao

API thay đổi lặp nhanh giống FE.

Deploy API → test ngay → revert 1 click.

✅ Cấu trúc code trong tapi buộc phải clean

Bất kỳ “logic phụ thuộc context runtime lâu dài” đều trở nên lộ rõ và bị loại bỏ.

Code trở nên “tĩnh” hơn, dễ audit, dễ chia sẻ.

Serverless vô tình tạo một khuôn kỷ luật cho dev backend.


Điều mình nghĩ cần chuẩn bị nếu bạn muốn theo hướng này

  • Đừng coi serverless như VPS miễn phí — cách vận hành hoàn toàn khác.
  • Hãy chọn DB phù hợp serverless (connection pooling, HTTP driver).
  • Kiến trúc theo hướng “stateless + shared database + shared cache”.
  • Kiểm soát build size & dependency — bundling rất quan trọng.


Note, không phải dự án nào cũng phù hợp

✅ Rất phù hợp (Nên):
  • CMS, SaaS vừa và nhỏ
  • Content API, API cho các internal tool
❌ Cần cân nhắc (Không nên):
  • Service yêu cầu latency cực thấp (ultra-low latency)
  • Hệ thống giao dịch real-time (real-time trade engine)
⭐ Combo hoàn hảo cho MVP:
  • Nếu bạn muốn MVP nhanh nhất có thể: Vercel + Postgres (serverless) + Prisma là một lựa chọn tuyệt vời.

-> Với vai trò Software Engineer việc đáng giá bài toán và lữa chọn giải pháp là yêu cầu tiên quyết hãy lựa chọn cẩn thận.

Trong dự án như tapi, Vercel mang lại một mô hình triển khai hiện đại, nhanh nhẹn, và đặc biệt phù hợp với developer thích TypeScript end-to-end.