REST vs GraphQL vs gRPC — kapan kowe milih saben siji?

Question

IT Interview Practice · Accepted Answer

Iki telung paradigma API sing beda, saben dioptimalake kanggo watesan sing beda. Ora ana pemenang universal — pilihan sing bener gumantung marang **konsumen, wangun data, lan jaringan**.

## Telu-telune sakilat

```text
           REST                 GraphQL              gRPC
Gaya       resource + HTTP      siji query graph     RPC (nyeluk method)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (biner)
Njupuk     endpoint tetep       client milih field   method tetep
Schema     opsional (OpenAPI)   kuwat, ber-tipe      kuwat, .proto
Browser    native, bisa cache   butuh client lib     winates (butuh proxy)
```

## REST

Berorientasi resource ing HTTP biasa. **Pilih iki** kanggo public API, layanan CRUD, lan apa wae sing entuk manfaat saka HTTP caching, sipat umum, lan prasaja. Kelemahane yaiku **over-fetching** (kowe entuk kabeh `/users/42` senajan mung butuh siji field) lan **under-fetching** (masalah `N+1`: njupuk siji user, banjur ngeloop kanggo njupuk saben order).

```http
GET /users/42            → kabeh user
GET /users/42/orders     → round trip kaping pindho
```

## GraphQL

Siji endpoint ing ngendi **client nemtokake persis apa sing dikarepake** ing siji query, ngrampungake over/under-fetching. **Pilih iki** kanggo frontend sing sugih (utamane mobile, ing ngendi round trip larang) lan nalika akeh client butuh wangun beda saka data sing padha.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← siji round trip, field pas
```
Trade-off: HTTP caching luwih angel (kabeh iku `POST` menyang `/graphql`), lan resolver sing naif bisa ndhelikake query database `N+1` sing larang.

## gRPC

RPC contract-first nganggo **Protobuf** ing **HTTP/2**. Biner lan multiplex, mula cepet lan ringkes kanthi dhukungan streaming. **Pilih iki** kanggo komunikasi **service-to-service internal** ing backend microservices ing ngendi performa lan tipe sing ketat penting. Kelemahan: dhukungan browser ala (butuh proxy kaya grpc-web) lan ora bisa diwaca manungsa.

## Milih

```text
Public API, CRUD, caching, jangkauan amba → REST
Kabutuhan data frontend rumit/maneka       → GraphQL
Microservices internal performa dhuwur     → gRPC
(Sistem nyata nyampur kabeh: REST/GraphQL ing pinggir, gRPC antar service.)
```

## Kenapa iki penting

Ing level senior, pewawancara kurang preduli babagan definisi lan luwih babagan apa kowe bisa **mbeneraken pilihan marang watesan** — pitakonan iki sabenere "apa kowe bisa nyocogake teknologi karo masalah tinimbang mburu hype?" Jawaban sing paling kuat nyantol ing lara sing dirampungake saben siji: GraphQL ana kanggo mateni over/under-fetching kanggo frontend sing njaluk akeh, gRPC ana kanggo ndadekake panggilan service internal cepet lan ber-tipe kuwat, lan REST tetep dadi standar amarga HTTP caching, tooling, lan kakraban universal iku kaluwihan praktis sing gedhe banget kanggo public API lan API gaya CRUD. Sing wigati, insinyur senior nyathet yen iki **dudu salah siji** — arsitektur umum yaiku REST utawa GraphQL ing pinggir publik kanthi gRPC antarane microservice backend — lan nyebut trade-off konkret (risiko caching lan `N+1` GraphQL, crita browser gRPC sing lemah). Penalaran babagan kecocogan lan biaya kuwi, dudu kemampuan ngucapake fitur, sing dadi sinyale.

Telu-telune sakilat

REST

GraphQL

gRPC

Milih

Kenapa iki penting

Pitakon sing gegandhengan