REST vs GraphQL vs gRPC — kada biste odabrali svaki?

Question

IT Interview Practice · Accepted Answer

Ovo su tri različite API paradigme, svaka optimizirana za različita ograničenja. Nema univerzalnog pobjednika — pravi izbor ovisi o **potrošaču, obliku podataka i mreži**.

## Tri na prvi pogled

```text
           REST                 GraphQL              gRPC
Stil       resursi + HTTP       jedan query graph    RPC (poziv metoda)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (binarni)
Dohvat     fiksni endpointi     klijent bira polja   fiksne metode
Schema     opcionalno (OpenAPI) jak, tipiziran       jak, .proto
Browser    nativno, cacheable   treba client lib     ograničeno (treba proxy)
```

## REST

Orijentiran na resurse preko običnog HTTP-a. **Odaberite ga** za javne API-je, CRUD servise i sve što ima koristi od HTTP cachiranja, sveprisutnosti i jednostavnosti. Slabosti su mu **over-fetching** (dobijete cijeli `/users/42` čak i ako trebate jedno polje) i **under-fetching** (`N+1` problem: dohvatite korisnika, zatim petljom dohvaćate svaku narudžbu).

```http
GET /users/42            → cijeli korisnik
GET /users/42/orders     → drugi round trip
```

## GraphQL

Jedan endpoint gdje **klijent točno navodi što želi** u jednom upitu, rješavajući over/under-fetching. **Odaberite ga** za bogate frontendove (osobito mobilne, gdje su round tripovi skupi) i kad mnogo klijenata treba različite oblike istih podataka.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← jedan round trip, točna polja
```
Kompromisi: HTTP cachiranje je teže (sve je `POST` na `/graphql`), a naivni resolver može sakriti skupe `N+1` upite baze.

## gRPC

Contract-first RPC koristeći **Protobuf** preko **HTTP/2**. Binaran i multipleksiran, pa je brz i kompaktan uz podršku za streaming. **Odaberite ga** za **internu komunikaciju servis-servis** u microservices backendu gdje su performanse i strogo tipiziranje bitni. Slabost: loša podrška preglednika (treba proxy poput grpc-web) i nije ljudski čitljiv.

## Odabir

```text
Javni API, CRUD, cachiranje, širok doseg        → REST
Složene/raznolike potrebe frontenda za podacima → GraphQL
Interni microservisi visokih performansi        → gRPC
(Stvarni sustavi ih miješaju: REST/GraphQL na rubu, gRPC između servisa.)
```

## Zašto je to važno

Na senior razini ispitivače manje zanimaju definicije, a više možete li **opravdati izbor s obzirom na ograničenja** — ovo pitanje zapravo je "možete li uskladiti tehnologiju s problemom umjesto da jurite hype?". Najsnažniji odgovori usidruju se u bol koju svaki rješava: GraphQL postoji da ubije over/under-fetching za zahtjevne frontendove, gRPC postoji da učini interne pozive servisa brzima i strogo tipiziranima, a REST ostaje zadani izbor jer su HTTP cachiranje, alati i univerzalna poznatost golemi praktični aduti za javne i CRUD-stilske API-je. Ključno, senior inženjer napominje da **nije ili-ili** — uobičajena arhitektura je REST ili GraphQL na javnom rubu s gRPC-om između backend microservisa — i imenuje konkretne kompromise (rizici cachiranja i `N+1` kod GraphQL-a, slaba priča o pregledniku kod gRPC-a). To rezoniranje o prikladnosti i trošku, a ne sposobnost recitiranja značajki, jest signal.

Tri na prvi pogled

REST

GraphQL

gRPC

Odabir

Zašto je to važno

Povezana pitanja