REST vs GraphQL vs gRPC — khi nào chọn cái nào?

Question

IT Interview Practice · Accepted Answer

Đây là ba paradigm API khác nhau, mỗi cái tối ưu cho ràng buộc khác nhau. Không có người thắng tuyệt đối — lựa chọn đúng phụ thuộc vào **người dùng, hình dạng dữ liệu, và mạng**.

## Nhìn nhanh ba cái

```text
           REST                 GraphQL              gRPC
Phong cách resource + HTTP      một query graph      RPC (gọi method)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (nhị phân)
Lấy dữ liệu endpoint cố định    client chọn field    method cố định
Schema     tuỳ chọn (OpenAPI)   mạnh, có kiểu         mạnh, .proto
Browser    native, cache được   cần client lib       hạn chế (cần proxy)
```

## REST

Hướng tài nguyên trên HTTP thuần. **Chọn nó** cho public API, dịch vụ CRUD, và bất cứ thứ gì hưởng lợi từ HTTP caching, sự phổ biến và tính đơn giản. Điểm yếu là **over-fetching** (bạn nhận cả `/users/42` dù chỉ cần một field) và **under-fetching** (vấn đề `N+1`: lấy một user, rồi lặp để lấy từng order).

```http
GET /users/42            → toàn bộ user
GET /users/42/orders     → một round trip thứ hai
```

## GraphQL

Một endpoint duy nhất nơi **client chỉ định chính xác thứ nó cần** trong một query, giải quyết over/under-fetching. **Chọn nó** cho frontend phong phú (nhất là mobile, nơi round trip tốn kém) và khi nhiều client cần các hình dạng khác nhau của cùng dữ liệu.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← một round trip, đúng field
```
Đánh đổi: HTTP caching khó hơn (mọi thứ là `POST` tới `/graphql`), và resolver ngây thơ có thể giấu các truy vấn `N+1` tốn kém.

## gRPC

RPC theo hợp đồng dùng **Protobuf** trên **HTTP/2**. Nhị phân và multiplex, nên nhanh, gọn và hỗ trợ streaming. **Chọn nó** cho giao tiếp **service-to-service nội bộ** trong backend microservices nơi hiệu năng và kiểu chặt quan trọng. Điểm yếu: hỗ trợ browser kém (cần proxy như grpc-web) và không đọc được bằng mắt.

## Cách chọn

```text
Public API, CRUD, caching, phủ rộng     → REST
Nhu cầu dữ liệu frontend phức tạp/đa dạng → GraphQL
Microservices nội bộ hiệu năng cao       → gRPC
(Hệ thực tế trộn cả ba: REST/GraphQL ở biên, gRPC giữa các service.)
```

## Tại sao điều này quan trọng

Ở cấp senior, người phỏng vấn ít quan tâm định nghĩa mà quan tâm bạn có thể **biện minh lựa chọn dựa trên ràng buộc** hay không — câu này thực chất là "bạn khớp công nghệ với vấn đề hay chạy theo hype?". Câu trả lời mạnh nhất neo vào nỗi đau mỗi cái giải quyết: GraphQL tồn tại để diệt over/under-fetching cho frontend đòi hỏi, gRPC tồn tại để làm gọi service nội bộ nhanh và kiểu chặt, còn REST vẫn là mặc định vì HTTP caching, tooling và sự quen thuộc phổ quát là lợi thế thực tế khổng lồ cho public API và API kiểu CRUD. Quan trọng, kỹ sư senior lưu ý đây **không phải chọn một** — kiến trúc phổ biến là REST hoặc GraphQL ở biên public với gRPC giữa các microservice backend — và nêu các đánh đổi cụ thể (rủi ro caching và `N+1` của GraphQL, câu chuyện browser yếu của gRPC). Chính lối lập luận về sự phù hợp và chi phí đó, chứ không phải khả năng đọc thuộc tính năng, mới là tín hiệu.

Nhìn nhanh ba cái

REST

GraphQL

gRPC

Cách chọn

Tại sao điều này quan trọng

Câu hỏi liên quan