Kapan kowe bakal milih GraphQL tinimbang REST, lan kapan ora?

Question

IT Interview Practice · Accepted Answer

Milih adhedhasar **sapa sing ngonsumsi API lan sepira maneka warnane kebutuhan datane** — dudu adhedhasar hype. GraphQL menang nalika akeh klien sing maneka warna butuh mbentuk data-e dhewe; REST menang nalika request-e seragam, bisa di-cache, lan prasaja.

## Pilih GraphQL nalika

- **Akeh klien kanthi kebutuhan beda** — web, iOS, Android saben pengin field sing beda saka entitas sing padha. GraphQL mateni over/under-fetching mula kowe ora perlu ngirim endpoint anyar saben layar.
- **Data sing gegandhengan jero/kaya graph** — siji query nlusur relasi (`user -> posts -> comments`) tinimbang N round trip REST.
- **Iterasi produk cepet** — evolusi schema aditif ngidini tim frontend nambah field tanpa ngenteni endpoint utawa versi backend anyar.
- **Nggabungake microservice** — gateway federated nampilake siji graph ing sadhuwure akeh layanan (pola BFF).

## Pilih REST nalika

- **Resource prasaja lan seragam** kanthi akses sing bisa diprediksi — CRUD ing ngendi saben klien pengin wangun sing padha.
- **Caching HTTP / CDN paling penting** — model URL + `GET` REST nge-cache kanthi gampang ing saben lapisan; GraphQL mbutuhake persisted query kanggo nyedhaki.
- **Unggah/undhuh file, biner, utawa API publik** ing ngendi piranti sing amba, kode status, lan kesederhanaan menang.
- **Tim cilik / kompleksitas rendah** — biaya sisih server GraphQL (resolver, kontrol N+1, watesan biaya query, piranti schema) ora sepadan kanggo mung sethithik endpoint.

## Tabel trade-off sing jujur

| Prakawis | GraphQL | REST |
|---|---|---|
| Over/under-fetching | Wis rampung miturut desain | Masalah umum |
| Caching HTTP/CDN | Angel (butuh gawean) | Alami lan gampang |
| Kontrol biaya query/DoS | Kudu kowe tambahake | Alami kawatesan |
| Keluwesan klien | Dhuwur | Cendhek |
| Kompleksitas server | Luwih dhuwur | Luwih cendhek |

Loro-lorone uga ora eksklusif — akeh sistem nampilake REST kanggo endpoint publik/bisa di-cache lan GraphQL kanggo klien internal sing sugih.

## Kenapa iki penting

Pewawancara senior nguji **pertimbangan, dudu kasetyan**. Jawaban sing kuat nyebut sumbune — keragaman klien, kebutuhan caching, kadewasan tim, permukaan DoS — lan ngakoni biaya nyata GraphQL (caching lan kontrol biaya query) tinimbang ngedol iku kaya luwih apik sacara universal.

Prakawis	GraphQL	REST
Over/under-fetching	Wis rampung miturut desain	Masalah umum
Caching HTTP/CDN	Angel (butuh gawean)	Alami lan gampang
Kontrol biaya query/DoS	Kudu kowe tambahake	Alami kawatesan
Keluwesan klien	Dhuwur	Cendhek
Kompleksitas server	Luwih dhuwur	Luwih cendhek

Pilih GraphQL nalika

Pilih REST nalika

Tabel trade-off sing jujur

Kenapa iki penting

Pitakon sing gegandhengan