GraphQL đang trở thành lựa chọn phổ biến cho các dự án API hiện đại, nhưng REST vẫn là tiêu chuẩn được dùng rộng rãi nhất. Bài viết này so sánh GraphQL và REST API một cách thực tế để giúp bạn quyết định nên chọn kiến trúc nào cho dự án mới của mình.
REST API và GraphQL khác nhau thế nào?
REST API hoạt động theo mô hình nhiều endpoint, mỗi endpoint trả về một cấu trúc dữ liệu cố định. Muốn lấy dữ liệu từ ba resource liên quan, bạn phải gọi ba request riêng biệt, và mỗi response thường chứa nhiều field không cần thiết — gọi là over-fetching. GraphQL chỉ dùng một endpoint duy nhất, client tự khai báo chính xác các field cần lấy, gom tất cả vào một request duy nhất. Theo IBM Think, đây chính là khác biệt cốt lõi: REST trả về cấu trúc cố định do server quyết định, còn GraphQL để client quyết định.
Bảng so sánh GraphQL và REST
| Tiêu chí | REST API | GraphQL |
|---|---|---|
| Lấy dữ liệu | Nhiều endpoint, cấu trúc cố định | Một endpoint, client chọn field |
| Over/under-fetching | Thường xuyên xảy ra | Không xảy ra |
| Versioning | Cần /v1, /v2 khi thay đổi | Thêm field mới không phá vỡ client cũ |
| Cache HTTP | Hỗ trợ tự nhiên, thân thiện CDN | Khó cache, cần giải pháp riêng |
| Real-time | Không có sẵn, cần SSE/WebSocket | Subscription có sẵn |
| Công cụ | Trưởng thành, phổ biến | Schema, introspection, codegen mạnh |
Hiệu năng thực tế từ các công ty lớn
Shopify là một ví dụ điển hình. Theo Shopify Enterprise Blog, công ty cắt giảm tới 75% chi phí query GraphQL trong năm trước khi quyết định “all-in” vào GraphQL vào tháng 10 năm 2024. Trong một case study của Shopify Partners, công ty Fisher Technology giảm từ 200.000 request REST xuống còn 40.000 request GraphQL khi đồng bộ 40.000 hồ sơ khách hàng — ít hơn 5 lần số request, và thời gian đồng bộ giảm từ 2-3 ngày xuống còn khoảng 2 giờ.
GitHub cũng xây dựng GraphQL API v4 với mục tiêu “thay thế nhiều request REST bằng một request duy nhất” theo tài liệu chính thức của GitHub. Lưu ý: các con số hiệu năng trên đều đến từ báo cáo của chính các công ty, chưa có benchmark trung lập độc lập nào công bố.
Khi nào nên chọn GraphQL?
- Mô hình dữ liệu phức tạp: nhiều resource liên quan nhau, cần lấy cùng lúc.
- Nhiều client khác nhau: mobile cần payload nhỏ, web cần dữ liệu đầy đủ hơn.
- Yêu cầu frontend thay đổi nhanh: thêm field mới không cần version API mới.
- Băng thông hạn chế: cần giảm số lượng request.
- Cần real-time: subscription của GraphQL hỗ trợ sẵn.
Khi nào nên giữ REST API?
- CRUD đơn giản, ứng dụng nhỏ: REST đủ dùng, không cần thêm độ phức tạp.
- API công khai cho bên thứ ba: Stripe, Twitter vẫn xây dựng trên REST.
- Cần cache HTTP và CDN: REST cache tự nhiên, GraphQL phải xử lý thủ công.
- Team nhỏ, cần MVP nhanh: công cụ REST trưởng thành và quen thuộc hơn.
Rủi ro khi dùng GraphQL
Điểm yếu lớn nhất của GraphQL là query phức tạp có thể làm quá tải database nếu không có giới hạn độ sâu và giới hạn số lượng record. Cần xây dựng cơ chế rate limiting và kiểm soát query ngay từ đầu. Ngoài ra, cache HTTP vốn miễn phí với REST lại là bài toán khó với GraphQL, thường phải dùng persisted queries hoặc cache phía server theo phân tích của HackerNoon.
Kết luận
Thực tế nhiều hệ thống lớn đang dùng mô hình hybrid: REST cho API công khai ổn định, GraphQL cho frontend nội bộ phức tạp. Với dự án mới, hãy bắt đầu từ REST nếu dữ liệu đơn giản, chuyển sang GraphQL khi frontend cần linh hoạt và mô hình dữ liệu trở nên phức tạp. GraphQL mạnh ở khả năng linh hoạt và giảm request, nhưng kèm theo trách nhiệm quản trị query chặt chẽ hơn.
