REST vs GraphQL vs gRPC — bila anda akan memilih setiap satu?

Question

IT Interview Practice · Accepted Answer

Ini tiga paradigma API yang berbeza, masing-masing dioptimumkan untuk kekangan berbeza. Tiada pemenang universal — pilihan yang betul bergantung pada **pengguna, bentuk data, dan rangkaian**.

## Ketiga-tiganya sepintas lalu

```text
           REST                 GraphQL              gRPC
Gaya       resource + HTTP      satu query graph     RPC (panggil method)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (binari)
Mengambil  endpoint tetap       client pilih field   method tetap
Schema     pilihan (OpenAPI)    kuat, bertaip        kuat, .proto
Browser    native, cacheable    perlu client lib     terhad (perlu proxy)
```

## REST

Berorientasikan sumber di atas HTTP biasa. **Pilihnya** untuk public API, service CRUD, dan apa-apa yang mendapat manfaat daripada HTTP caching, kelaziman, dan kesederhanaan. Kelemahannya ialah **over-fetching** (anda mendapat keseluruhan `/users/42` walaupun hanya perlukan satu field) dan **under-fetching** (masalah `N+1`: ambil user, kemudian gelung untuk mengambil setiap order).

```http
GET /users/42            → keseluruhan user
GET /users/42/orders     → round trip kedua
```

## GraphQL

Satu endpoint tunggal di mana **client menentukan dengan tepat apa yang ia mahu** dalam satu query, menyelesaikan over/under-fetching. **Pilihnya** untuk frontend kaya (terutamanya mobile, di mana round trip mahal) dan apabila banyak client memerlukan bentuk berbeza bagi data yang sama.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← satu round trip, field tepat
```
Trade-off: HTTP caching lebih sukar (segala-galanya ialah `POST` ke `/graphql`), dan resolver naif boleh menyembunyikan query pangkalan data `N+1` yang mahal.

## gRPC

RPC berpandukan kontrak menggunakan **Protobuf** di atas **HTTP/2**. Binari dan dimultipleks, jadi ia pantas dan padat dengan sokongan streaming. **Pilihnya** untuk komunikasi **service-to-service dalaman** dalam backend microservices di mana prestasi dan penaipan ketat penting. Kelemahan: sokongan browser lemah (perlukan proxy seperti grpc-web) dan tidak boleh dibaca manusia.

## Cara memilih

```text
Public API, CRUD, caching, jangkauan luas → REST
Keperluan data frontend kompleks/pelbagai → GraphQL
Microservices dalaman berprestasi tinggi  → gRPC
(Sistem sebenar mencampurkannya: REST/GraphQL di pinggir, gRPC antara service.)
```

## Mengapa ia penting

Pada peringkat senior, penemu duga kurang mengambil berat tentang definisi dan lebih tentang sama ada anda boleh **mewajarkan pilihan terhadap kekangan** — soalan ini sebenarnya "bolehkah anda memadankan teknologi dengan masalah dan bukannya mengejar hype?" Jawapan paling kukuh berlabuh pada kesakitan yang setiap satu selesaikan: GraphQL wujud untuk membunuh over/under-fetching bagi frontend yang menuntut, gRPC wujud untuk menjadikan panggilan service dalaman pantas dan bertaip kuat, manakala REST kekal menjadi lalai kerana HTTP caching, tooling, dan kebiasaan universal ialah kelebihan praktikal yang besar untuk public API dan API bergaya CRUD. Yang penting, jurutera senior menyatakan ia **bukan salah satu** — seni bina lazim ialah REST atau GraphQL di pinggir awam dengan gRPC antara microservice backend — dan menamakan trade-off konkrit (risiko caching dan `N+1` GraphQL, cerita browser lemah gRPC). Penaakulan tentang kesesuaian dan kos itu, bukan keupayaan melafazkan ciri, itulah isyaratnya.

Ketiga-tiganya sepintas lalu

REST

GraphQL

gRPC

Cara memilih

Mengapa ia penting

Soalan berkaitan