Login

GraphQL hay REST? Chọn kiểu API phù hợp với dự án của bạn

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

GraphQL được nhiều người nhắc đến như người kế nhiệm REST, nhưng thực tế hai kiểu API này giải quyết bài toán hơi khác nhau. Chọn cái nào phụ thuộc vào ứng dụng khách của bạn cần gì, và đội ngũ của bạn đã quen gì.

REST: nhiều endpoint, mỗi cái một tài nguyên

Với REST, mỗi tài nguyên có một địa chỉ, server quyết định hình dạng dữ liệu trả về. Để hiển thị trang hồ sơ có thông tin người dùng, bài viết gần đây và số người theo dõi, ứng dụng có thể phải gọi ba endpoint:

GET /users/12GET /users/12/posts?limit=5GET /users/12/followers/count

Hai vấn đề quen thuộc có thể xuất hiện: over-fetching (nhận về nhiều trường hơn cần) và under-fetching (phải gọi nhiều lần mới đủ dữ liệu).

GraphQL: một endpoint, client mô tả điều cần

GraphQL có thường chỉ một endpoint. Client gửi truy vấn mô tả chính xác các trường nó muốn và nhận về đúng như vậy:

query {  user(id: 12) {    name    avatarUrl    posts(limit: 5) { title createdAt }    followersCount  }}

Một request, đủ dữ liệu, không thừa. Server định nghĩa một schema có kiểu rõ ràng, và đây cũng là tài liệu sống của API:

type User {  id: ID!  name: String!  posts(limit: Int = 10): [Post!]!  followersCount: Int!}type Query {  user(id: ID!): User}

Thay đổi dữ liệu dùng mutation, còn nhận cập nhật theo thời gian thực dùng subscription.

Khi GraphQL tỏa sáng

  • Nhiều loại client (web, di động, thiết bị khác) cần các tập dữ liệu khác nhau từ cùng một backend.
  • Giao diện phức tạp, dữ liệu lồng nhau nhiều tầng, muốn giảm số lần gọi mạng, đặc biệt trên mạng di động chậm.
  • Front-end muốn thay đổi nhu cầu dữ liệu nhanh mà không đợi backend thêm endpoint mới.

Cái giá phải trả

  • Cache khó hơn: REST tận dụng cache HTTP theo URL rất tự nhiên, còn GraphQL thường dùng POST đến một địa chỉ nên cần chiến lược cache riêng.
  • Vấn đề N+1 ở phía server: mỗi trường có hàm resolver riêng, dễ gọi database lặp đi lặp lại; thường phải dùng cơ chế gom nhóm như DataLoader.
  • Truy vấn nặng và độc hại: client có thể gửi truy vấn lồng sâu hoặc rất rộng làm quá tải server; cần giới hạn độ sâu, độ phức tạp và có thời hạn.
  • Phân quyền theo trường: phải kiểm soát chi tiết hơn.
  • Độ phức tạp vận hành: thêm công cụ, thêm khái niệm cho cả nhóm học.

Khi REST vẫn là lựa chọn tốt

REST rất phù hợp với API công khai đơn giản, thao tác CRUD, dịch vụ giữa các hệ thống (server-to-server), tải tệp và những nơi cần cache HTTP mạnh. Nó dễ hiểu, công cụ phong phú, hầu như lập trình viên nào cũng biết. Một API REST được thiết kế tốt thường là đủ cho đa số dự án.

Bảng đối chiếu

Tiêu chíRESTGraphQL
Số endpointNhiềuThường một
Hình dạng dữ liệuServer quyết địnhClient quyết định
CacheCache HTTP dễCần giải pháp riêng
Đường cong họcThấpCao hơn
Tài liệuOpenAPISchema tự mô tả

Có thể dùng cả hai

Không ít hệ thống giữ REST cho các tác vụ đơn giản và tích hợp bên ngoài, đồng thời thêm một lớp GraphQL phía trước cho ứng dụng giao diện phức tạp. Lớp này có thể đóng vai trò cổng gom dữ liệu từ nhiều dịch vụ phía sau. Hãy bắt đầu từ vấn đề thật mà bạn đang gặp thay vì chạy theo xu hướng.

Một vài lưu ý khi triển khai GraphQL

Nếu quyết định dùng GraphQL, hãy lên kế hoạch cho các vấn đề vận hành ngay từ đầu. Thứ nhất, đặt giới hạn: độ sâu truy vấn tối đa, số phần tử tối đa mỗi danh sách, thời gian thực thi tối đa. Thứ hai, tắt hoặc hạn chế tính năng introspection ở môi trường production nếu API không công khai. Thứ ba, ghi log theo tên thao tác (operation name) thay vì chỉ thấy một đường dẫn duy nhất, để biết truy vấn nào đang chậm. Cuối cùng, đầu tư vào công cụ sinh kiểu dữ liệu cho client từ schema, vì lợi ích lớn nhất của GraphQL là hợp đồng kiểu chặt chẽ giữa hai phía.

Kết luận

Nếu ứng dụng nhỏ và bạn chưa gặp vấn đề over-fetching, hãy cứ dùng REST. Khi nhiều client có nhu cầu đa dạng và giao diện phức tạp, hãy thử GraphQL ở một phần nhỏ trước. Quyết định tốt đến từ việc hiểu rõ đánh đổi, không phải từ việc chọn thứ nghe hiện đại hơn.

Muốn học bài bản và có lộ trình rõ ràng? Bạn có thể xem các khóa học trên codebem.com.

author_photo
Nguyễn Đình Cường

0 comment