Tôi từng có một đêm thứ ba hoàng tráng. Team của tôi vừa deploy một API REST mới, tất cả mừng rỡ. Đến thứ năm, mobile team gọi: "API này trả về 50 field nhưng chúng tôi chỉ cần 3 cái". Và như vậy, đêm thứ ba đó thành dư âm của hàng tuần refactor. Có lẽ bạn cũng từng ở vị trí đó.
Đó là khoảnh khắc nói với tôi rằng REST không phải lúc nào cũng hoàn hảo. Và GraphQL? Cũng không phải lúc nào cũng là câu trả lời.
Vấn đề REST mà không ai muốn thừa nhận
REST có 50 năm lịch sử (nếu tính từ những ý tưởng ban đầu), và nó tuyệt vời khi bạn đơn giản là muốn lấy dữ liệu theo resource. Nhưng hãy nhìn sự thật trần trụi:
Khi bạn xây dựng một ứng dụng mobile với mạng 4G chậm, mỗi byte đều quan trọng. REST sẽ cho bạn user, posts, comments, likes—toàn bộ những thứ bạn không cần. Hoặc ngược lại, bạn cần user.profile.settings.notifications.email? Vậy phải gọi 5 endpoint khác nhau (over-fetching vs under-fetching—tên gọi khôn khéo cho một vấn đề cơ bản của thiết kế).
Facebook xác định vấn đề này vào 2012 khi mobile team của họ chết ngạt trong mưa API call. Nó dẫn đến việc Lee Byron bắt đầu viết GraphQL.
GraphQL: Công cụ lợi nhất, hay lỗi lớn nhất?
GraphQL cho phép client nói: "Tôi cần đúng những thứ này, không hơn không kém". Đó là lý tưởng trên giấy. Trong thực tế?
Tôi đã nhìn thấy đội GraphQL có 15 người maintain một cái server đơn giản để phục vụ 3 client khác nhau, mỗi client đều có 200 dòng query schema được custom. Complexity tăng exponential. Database query cũng như vậy—nếu không cẩn thận, một GraphQL query có thể tạo ra 1000 sub-query (gọi là N+1 problem, nhưng trên GraphQL nó còn quái đản hơn).
Chia sẻ bài viết
Bài viết liên quan
Bạn cần tư vấn về công nghệ?
Đội ngũ Idflow luôn sẵn sàng hỗ trợ bạn trong hành trình chuyển đổi số.
Nhưng—và đây là điểm quan trọng—khi bạn thiết kế tốt, GraphQL giảm traffic 40-60% so với REST trên mobile. Con số này từ nghiên cứu của Apollo & Hasura. Startup ở Hà Nội mà tôi từng làm việc chuyển sang GraphQL, chi phí data center giảm 30%. Đó là tiền thật.
Khi nào REST còn là vua
Nếu API của bạn có 20 endpoint, mỗi endpoint rất rõ ràng (GET /users/123, POST /orders, DELETE /posts/456), và client của bạn là web browser hoặc native app với connection ổn định—REST là vàng. Nó đơn giản, dễ cache (HTTP cache hoạt động tự nhiên), dễ debug (curl là bạn thân).
Công ty ecommerce lớn ở TP.HCM vẫn dùng REST. Tại sao? Vì họ có infrastructure team mạnh, họ optimize ở tầng khác (caching, CDN, database indexing), và REST khiến operations đơn giản hơn 10 lần.
REST cũng tốt hơn nếu:
- Team bạn nhỏ (<5 người backend)
- API của bạn công khai và nhiều third-party integrate
- Bạn cần monitoring/logging sơ đẳng (logging 1000 dòng GraphQL query không fun)
- SEO quan trọng (REST + GET dễ cache hơn POST GraphQL)
Thừa nhận sự thật không thoải mái
GraphQL không phải lúc nào cũng nhanh hơn. Query GraphQL phức tạp có thể chậm hơn nhiều REST call. Tôi đã benchmark nhiều lần—5 endpoint REST đơn giản beat lại 1 GraphQL query dài 200 dòng, vì parser + execution time của GraphQL thêm overhead.
REST cũng không phải lúc nào là bad. Nhưng nếu bạn có 50 client khác nhau (web, mobile, tablet, smart TV, chatbot), REST sẽ khiến backend team mình bị điên. Đó là lúc GraphQL bắt đầu có ý nghĩa.
Câu hỏi bạn nên tự hỏi
1Team size: Có đủ người để maintain GraphQL complexity không?
2Client diversity: Bao nhiêu client khác nhau cần consume API?
3Network condition: Client chạy trên 3G hay 5G?
4Query complexity: Relationship giữa data có phức tạp không?
Nếu trả lời 3-4 câu "không", hãy dùng REST. Nếu 3-4 câu "có", GraphQL thường là lựa chọn tốt.
Hybrid approach (chân lý ít ai nói)
Một số công ty lớn làm cả hai. Netflix dùng GraphQL internally nhưng expose REST API cho partners. Shopify dùng GraphQL cho merchant API (complex), nhưng REST cho simple webhooks.
Hybrid approach này cost cao hơn, nhưng flexibility đó có giá. Nếu bạn grow fast (startup), đây có thể là path hợp lý.
---
Chọn giữa GraphQL vs REST không phải là lựa chọn công nghệ—đó là lựa chọn kiến trúc. Nó ảnh hưởng tới làm cách nào team bạn scale, cách bạn debug, cách bạn monitor. Hãy tưởng tượng bạn chọn sai, rồi phải rewrite sau 2 năm khi có 10 triệu user. Nhưng cũng đừng over-think—nếu bạn optimize tốt ở tầng khác, cả hai cách đều có thể work.
Tại Idflow Technology, chúng tôi đã help không ít startup lựa chọn đúng cách, bước vào scaling mà không cần refactor API sau này.
