Trả lời nhanh: GraphQL là cách thiết kế API mà bên gọi tự khai báo cần đúng những trường nào, thay vì nhận trọn gói dữ liệu do máy chủ định sẵn. Lợi ích rõ nhất xuất hiện khi một màn hình cần ghép dữ liệu từ nhiều nguồn, hoặc khi ứng dụng di động muốn tiết kiệm băng thông. Cái giá là phía máy chủ phức tạp hơn hẳn, và có ba bẫy hiệu năng mà REST không có. Với dự án nhỏ hoặc API chỉ phục vụ một ứng dụng, REST vẫn là lựa chọn đúng.
GraphQL được nhắc tới nhiều tới mức nhiều đội chọn nó vì sợ tụt hậu chứ không vì có vấn đề cần giải. Bài này nói thẳng nó giải quyết đúng vấn đề gì, đổi lại lấy đi cái gì, để bạn quyết định dựa trên tình huống thật của mình.
Khác biệt cốt lõi
Với REST, máy chủ quyết định mỗi điểm cuối trả về gì. Muốn thông tin người dùng kèm danh sách đơn hàng, bạn gọi hai lần, hoặc máy chủ phải làm thêm một điểm cuối gộp.
GET /api/nguoi-dung/12GET /api/nguoi-dung/12/don-hangVới GraphQL, bên gọi mô tả cái mình cần trong một lần:
{ nguoiDung(id: 12) { ten email donHang(gioiHan: 5) { ma tongTien } }}Kết quả trả về đúng hình dạng đó, không thừa trường nào. Với ứng dụng di động chạy mạng di động, chênh lệch dung lượng này cảm nhận được. Và quan trọng hơn: khi giao diện đổi yêu cầu dữ liệu, phía trước tự đổi truy vấn mà không cần phía sau làm thêm điểm cuối mới.
Khi nào GraphQL thật sự đáng
Bốn tình huống rõ ràng:
- Nhiều loại giao diện dùng chung một API. Web, ứng dụng di động, đồng hồ thông minh cần các tập trường khác nhau từ cùng dữ liệu.
- Màn hình ghép nhiều nguồn. Một trang tổng quan lấy dữ liệu từ bốn năm bảng hoặc dịch vụ, mà với REST sẽ thành bốn năm lượt gọi nối tiếp.
- Phía trước thay đổi nhanh. Đội giao diện tự lấy được dữ liệu mới mà không phải chờ đội backend làm điểm cuối.
- Băng thông là vấn đề thật. Ứng dụng phục vụ người dùng ở vùng mạng yếu.
Nếu dự án của bạn không rơi vào nhóm nào ở trên, khả năng cao REST vẫn phục vụ tốt hơn với ít công sức hơn nhiều.
Ba bẫy hiệu năng phải biết trước
Truy vấn lồng nhau sinh ra rất nhiều lượt hỏi database. Lấy hai mươi bài viết kèm tác giả, nếu viết ngây thơ thì thành một lượt lấy bài cộng hai mươi lượt lấy tác giả. Cách chữa là gom các lượt hỏi cùng loại trong một vòng xử lý rồi hỏi database một lần. Đây là việc bắt buộc phải làm chứ không phải tối ưu về sau.
Truy vấn quá nặng. Vì bên gọi tự viết truy vấn, một câu lồng năm tầng có thể kéo cả nửa database. Phải đặt giới hạn độ sâu và độ phức tạp, đặc biệt với API mở ra ngoài.
Bộ nhớ đệm khó hơn. REST đặt bộ nhớ đệm ở tầng HTTP rất tự nhiên vì mỗi đường dẫn ứng với một tài nguyên. GraphQL thường chỉ có một điểm cuối và mọi thứ đi qua phương thức gửi, nên bạn phải làm bộ nhớ đệm ở tầng ứng dụng.
Ba điều này không phải lý do để tránh GraphQL, nhưng chúng là công việc thật mà bạn phải làm, và chúng là lý do một API GraphQL viết vội thường chậm hơn REST tương đương.
Chi phí phía máy chủ
Ngoài ba bẫy trên, còn vài khoản đầu tư ban đầu:
- Định nghĩa lược đồ và bộ giải cho từng trường. Nhiều mã hơn REST cho cùng lượng dữ liệu.
- Xử lý lỗi khác kiểu. GraphQL thường trả về mã thành công kèm phần lỗi trong nội dung, nên tầng theo dõi của bạn phải hiểu điều đó, nếu không mọi thứ trông như đang chạy tốt.
- Phân quyền phức tạp hơn. Với REST bạn kiểm tra ở từng điểm cuối. Với GraphQL phải kiểm tra ở tầng trường, vì một truy vấn có thể chạm tới nhiều loại dữ liệu cùng lúc.
Điểm cuối này hay bị xem nhẹ và là nguồn lỗ hổng thật: một trường nhạy cảm quên kiểm tra quyền có thể bị lấy qua đường lồng ghép từ một loại dữ liệu khác.
Chọn thế nào cho dự án của bạn
Chọn REST khi: API phục vụ đúng một ứng dụng; đội nhỏ và muốn đi nhanh; API công khai cho bên thứ ba, vì REST dễ dùng và dễ đặt bộ nhớ đệm hơn; hoặc dữ liệu vốn đơn giản và ít quan hệ. Cách thiết kế REST gọn nằm ở bài riêng trong cụm này.
Chọn GraphQL khi: nhiều loại giao diện dùng chung API; màn hình ghép nhiều nguồn; hoặc đội giao diện cần tự chủ về dữ liệu.
Dùng cả hai cũng được: nhiều hệ thống giữ REST cho các thao tác đơn giản và mở thêm một điểm cuối GraphQL cho những màn hình phức tạp. Không có luật nào bắt bạn chọn một.
Và nhớ điều này dù chọn hướng nào: phần lớn trang chậm không phải vì tầng API mà vì truy vấn database, theo đúng thứ tự chẩn đoán trong bài database chậm.
Khi nào thật sự đáng
| Tình huống | Có đáng không | Vì sao |
|---|---|---|
| Nhiều loại client cần dữ liệu khác nhau từ cùng nguồn | Đáng | Đây là bài toán nó sinh ra để giải |
| Ứng dụng di động cần giảm số lượt gọi mạng | Đáng | Lấy đủ thứ cần trong một lượt |
| Một ứng dụng web, một đội, dữ liệu đơn giản | Không đáng | Thêm phức tạp mà không đổi lại gì |
| Đội chưa ai làm bao giờ, dự án gấp | Không đáng | Học và vận hành là chi phí thật |
| Cần lưu đệm ở tầng mạng dễ dàng | Không đáng | Cách truyền thống lưu đệm dễ hơn nhiều |
Lời khuyên cho đội nhỏ ở Việt Nam: nếu bạn có một ứng dụng web và một ứng dụng di động dùng cùng dữ liệu, cách truyền thống vẫn đủ. Ngưỡng đáng chuyển thường là khi có từ ba loại client trở lên với nhu cầu dữ liệu khác nhau rõ rệt.
Truy vấn lồng nhau sinh ra hàng loạt truy vấn
- Truy vấn lồng nhau sinh ra rất nhiều truy vấn cơ sở dữ liệu. Một yêu cầu lấy danh sách kèm dữ liệu liên quan có thể sinh hàng trăm truy vấn nếu không xử lý. Đây là bẫy nghiêm trọng nhất và gần như ai cũng gặp.
- Người dùng có thể yêu cầu truy vấn rất sâu và rất nặng. Phải giới hạn độ sâu và độ phức tạp, nếu không một yêu cầu duy nhất làm chết máy chủ.
- Lưu đệm khó hơn hẳn cách truyền thống, vì mọi yêu cầu đi qua cùng một điểm và nội dung khác nhau.
Ba việc phải làm trước khi đưa vào chạy thật
# 1. Gioi han do sau va do phuc tap cua truy van# Khong gioi han la mo cua cho mot yeu cau lam chet may chu # 2. Xu ly van de truy van lap: gom nhieu truy van thanh mot# Do bang cach dem so truy van co so du lieu cho mot yeu cau# Bat nhat ky truy van cham va xem # 3. Tat kha nang tu kham pha luoc do tren moi truong that# No lo toan bo cau truc du lieu cho nguoi ngoai # Do so truy van thuc temysql -e "SET GLOBAL general_log='ON';"# gui mot yeu cau, roi dem so dong trong log# nho tat lai sau khi doChi phí phía máy chủ: cách này thường tốn nhiều tài nguyên hơn cách truyền thống ở cùng khối lượng, vì mỗi yêu cầu phải phân tích truy vấn và có thể chạm nhiều bảng. Tính vào cấu hình máy khi lập kế hoạch. Xem VPS NVMe.
Câu hỏi thường gặp
GraphQL có nhanh hơn REST không?
Không tự nhiên nhanh hơn. Nó giảm số lượt gọi mạng và giảm dữ liệu thừa, nhưng nếu phía máy chủ không gom các lượt hỏi database thì lại chậm hơn REST. Tốc độ đến từ cách bạn cài đặt chứ không từ giao thức.
Có cần bỏ REST khi chuyển sang GraphQL không?
Không. Rất nhiều hệ thống chạy song song: REST cho thao tác đơn giản và cho bên thứ ba, GraphQL cho các màn hình cần ghép dữ liệu. Chuyển dần từng phần cũng an toàn hơn là viết lại một lượt.
GraphQL có an toàn không?
An toàn nếu bạn kiểm tra quyền ở tầng trường và giới hạn độ sâu cùng độ phức tạp của truy vấn. Bỏ hai việc đó thì bên gọi có thể lấy dữ liệu ngoài phạm vi hoặc làm quá tải máy chủ bằng một câu truy vấn.
Máy chủ cần cấu hình gì để chạy GraphQL?
Không khác REST nhiều về CPU, nhưng tầng database chịu tải nặng hơn nếu truy vấn lồng sâu. Hãy ưu tiên ổ đĩa nhanh và đủ RAM cho bộ nhớ đệm, đó là nơi khác biệt thể hiện rõ nhất.