REST vs GraphQL vs gRPC — คุณจะเลือกแต่ละอันเมื่อไร?

Question

IT Interview Practice · Accepted Answer

ทั้งสามนี้เป็น paradigm ของ API ที่ต่างกัน แต่ละอันถูกปรับให้เหมาะกับข้อจำกัดที่ต่างกัน ไม่มีผู้ชนะสากล — การเลือกที่ถูกต้องขึ้นอยู่กับ **ผู้ใช้, รูปร่างของข้อมูล, และเครือข่าย**

## มองสามอันแบบรวดเร็ว

```text
           REST                 GraphQL              gRPC
Style      resources + HTTP     single query graph   RPC (call methods)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (binary)
Fetching   fixed endpoints      client picks fields  fixed methods
Schema     optional (OpenAPI)   strong, typed        strong, .proto
Browser    native, cacheable    needs client lib     limited (needs proxy)
```

## REST

มุ่งทรัพยากรบน HTTP ล้วน **เลือกมัน** สำหรับ public API, เซอร์วิส CRUD, และอะไรก็ตามที่ได้ประโยชน์จาก HTTP caching, ความแพร่หลาย, และความเรียบง่าย จุดอ่อนคือ **over-fetching** (คุณได้ทั้ง `/users/42` แม้ต้องการฟิลด์เดียว) และ **under-fetching** (ปัญหา `N+1`: ดึง user หนึ่งราย แล้ววนดึง order แต่ละอัน)

```http
GET /users/42            → the whole user
GET /users/42/orders     → a second round trip
```

## GraphQL

endpoint เดียวที่ **client ระบุสิ่งที่ต้องการอย่างแม่นยำ** ในหนึ่ง query แก้ปัญหา over/under-fetching **เลือกมัน** สำหรับ frontend ที่ซับซ้อน (โดยเฉพาะ mobile ที่ round trip แพง) และเมื่อ client หลายตัวต้องการข้อมูลเดียวกันในรูปร่างที่ต่างกัน

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
การแลกเปลี่ยน: HTTP caching ยากขึ้น (ทุกอย่างเป็น `POST` ไปที่ `/graphql`) และ resolver ที่เขียนแบบไร้เดียงสาอาจซ่อน query ฐานข้อมูลแบบ `N+1` ที่แพงไว้

## gRPC

RPC แบบสัญญามาก่อน (contract-first) ใช้ **Protobuf** บน **HTTP/2** เป็น binary และ multiplex จึงเร็ว กะทัดรัด พร้อมรองรับ streaming **เลือกมัน** สำหรับการสื่อสาร **service-to-service ภายใน** ใน backend แบบ microservices ที่ประสิทธิภาพและการมีชนิดที่เข้มงวดสำคัญ จุดอ่อน: รองรับเบราว์เซอร์ได้แย่ (ต้องใช้ proxy อย่าง grpc-web) และอ่านด้วยตาไม่ได้

## การเลือก

```text
Public API, CRUD, caching, wide reach   → REST
Complex/varied frontend data needs      → GraphQL
High-performance internal microservices → gRPC
(Real systems mix them: REST/GraphQL at the edge, gRPC between services.)
```

## ทำไมจึงสำคัญ

ที่ระดับ senior ผู้สัมภาษณ์สนใจนิยามน้อยกว่า และสนใจว่าคุณ **ให้เหตุผลสนับสนุนการเลือกโดยเทียบกับข้อจำกัด** ได้หรือไม่ — คำถามนี้จริง ๆ คือ "คุณจับคู่เทคโนโลยีกับปัญหา หรือไล่ตามกระแส?" คำตอบที่แข็งแรงที่สุดยึดกับความเจ็บปวดที่แต่ละอันแก้: GraphQL มีอยู่เพื่อฆ่า over/under-fetching สำหรับ frontend ที่เรียกร้องสูง, gRPC มีอยู่เพื่อทำให้การเรียกเซอร์วิสภายในเร็วและมีชนิดเข้มงวด, ส่วน REST ยังเป็นค่าดีฟอลต์เพราะ HTTP caching, เครื่องมือ, และความคุ้นเคยสากลเป็นข้อได้เปรียบเชิงปฏิบัติมหาศาลสำหรับ public API และ API สไตล์ CRUD ที่สำคัญ วิศวกร senior ตั้งข้อสังเกตว่ามัน **ไม่ใช่การเลือกอย่างใดอย่างหนึ่ง** — สถาปัตยกรรมที่พบบ่อยคือ REST หรือ GraphQL ที่ขอบ public พร้อม gRPC ระหว่าง backend microservice — และระบุการแลกเปลี่ยนที่เป็นรูปธรรม (ความเสี่ยงเรื่อง caching และ `N+1` ของ GraphQL, เรื่องเบราว์เซอร์ที่อ่อนแอของ gRPC) การให้เหตุผลเรื่องความเหมาะสมและต้นทุนนั้น ไม่ใช่ความสามารถในการท่องฟีเจอร์ คือสัญญาณที่แท้จริง

มองสามอันแบบรวดเร็ว

REST

GraphQL

gRPC

การเลือก

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง