REST vs GraphQL vs gRPC — kapan Anda memilih masing-masing?

Question

IT Interview Practice · Accepted Answer

Ini adalah tiga paradigma API yang berbeda, masing-masing dioptimalkan untuk constraint yang berbeda. Tidak ada pemenang universal — pilihan yang tepat bergantung pada **konsumen, bentuk data, dan jaringan**.

## Ketiganya sekilas

```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

Berorientasi resource di atas HTTP biasa. **Pilih ini** untuk public API, service CRUD, dan apa pun yang diuntungkan oleh HTTP caching, keberadaan di mana-mana, dan kesederhanaan. Kelemahannya adalah **over-fetching** (Anda mendapat seluruh `/users/42` bahkan jika Anda hanya butuh satu field) dan **under-fetching** (masalah `N+1`: ambil seorang user, lalu loop untuk mengambil setiap order).

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

## GraphQL

Sebuah endpoint tunggal di mana **client menentukan persis apa yang diinginkannya** dalam satu query, menyelesaikan over/under-fetching. **Pilih ini** untuk frontend yang kaya (terutama mobile, di mana round trip mahal) dan ketika banyak client membutuhkan bentuk berbeda dari data yang sama.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
Trade-off: HTTP caching lebih sulit (semuanya adalah `POST` ke `/graphql`), dan resolver yang naif bisa menyembunyikan query database `N+1` yang mahal.

## gRPC

RPC contract-first menggunakan **Protobuf** di atas **HTTP/2**. Biner dan ter-multiplex, sehingga cepat dan ringkas dengan dukungan streaming. **Pilih ini** untuk komunikasi **service-to-service internal** dalam backend microservices di mana performa dan pengetikan ketat penting. Kelemahan: dukungan browser buruk (butuh proxy seperti grpc-web) dan tidak dapat dibaca manusia.

## Memilih

```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.)
```

## Mengapa ini penting

Pada level senior, pewawancara kurang peduli pada definisi dan lebih peduli pada apakah Anda bisa **membenarkan sebuah pilihan terhadap constraint** — pertanyaan ini sebenarnya adalah "bisakah Anda mencocokkan teknologi dengan masalah alih-alih mengejar hype?" Jawaban terkuat berjangkar pada rasa sakit yang diselesaikan masing-masing: GraphQL ada untuk membunuh over/under-fetching bagi frontend yang menuntut, gRPC ada untuk membuat panggilan service internal cepat dan bertipe kuat, dan REST tetap menjadi default karena HTTP caching, tooling, dan keakraban universal adalah keunggulan praktis yang sangat besar untuk public API dan API bergaya CRUD. Yang krusial, seorang engineer senior mencatat ini **bukan pilih-satu** — arsitektur umum adalah REST atau GraphQL di edge publik dengan gRPC di antara microservice backend — dan menyebut trade-off konkretnya (risiko caching dan `N+1` milik GraphQL, cerita browser yang lemah milik gRPC). Penalaran tentang kecocokan dan biaya itu, bukan kemampuan membacakan fitur, adalah sinyalnya.

Ketiganya sekilas

REST

GraphQL

gRPC

Memilih

Mengapa ini penting

Pertanyaan terkait