REST proti GraphQL proti gRPC — kdaj bi izbrali katerega?

Question

IT Interview Practice · Accepted Answer

To so trije različni paradigmi API-jev, vsak optimiziran za drugačne omejitve. Univerzalnega zmagovalca ni — prava izbira je odvisna od **uporabnika, oblike podatkov in omrežja**.

## Trije na hitro

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

Usmerjen v vire prek navadnega HTTP. **Izberite ga** za javne API-je, storitve CRUD in vse, kar ima korist od predpomnjenja HTTP, vseprisotnosti in preprostosti. Njegovi slabosti sta **over-fetching** (dobite celoten `/users/42`, tudi če potrebujete eno polje) in **under-fetching** (težava `N+1`: pridobi uporabnika, nato v zanki pridobi vsako naročilo).

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

## GraphQL

En sam endpoint, kjer **odjemalec v eni poizvedbi natančno določi, kaj želi**, kar reši over/under-fetching. **Izberite ga** za bogate frontende (zlasti mobilne, kjer so povratna potovanja draga) in kadar veliko odjemalcev potrebuje različne oblike istih podatkov.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
Kompromisi: predpomnjenje HTTP je težje (vse je `POST` na `/graphql`), naiven resolver pa lahko skriva drage poizvedbe `N+1` v bazo.

## gRPC

Pogodbeno usmerjen RPC z **Protobuf** prek **HTTP/2**. Binaren in multipleksiran, zato je hiter in kompakten s podporo za streaming. **Izberite ga** za **notranjo komunikacijo med storitvami** v backendu z mikrostoritvami, kjer sta pomembna zmogljivost in strogo tipiziranje. Slabost: slaba podpora brskalnikov (potrebuje proxy, kot je grpc-web) in ni človeku berljiv.

## Kako izbrati

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

## Zakaj je to pomembno

Na senior ravni spraševalce manj zanimajo definicije, bolj pa, ali znate **izbiro utemeljiti glede na omejitve** — to vprašanje je v resnici "znaš tehnologijo ujeti s problemom, namesto da loviš hype?". Najmočnejši odgovori se zasidrajo na bolečini, ki jo vsak reši: GraphQL obstaja, da ubije over/under-fetching za zahtevne frontende, gRPC obstaja, da naredi notranje klice storitev hitre in strogo tipizirane, REST pa ostaja privzeta izbira, ker so predpomnjenje HTTP, orodja in univerzalna domačnost ogromne praktične prednosti za javne in CRUD-jevske API-je. Ključno je, da senior inženir opozori, da to **ni ali-ali** — pogosta arhitektura je REST ali GraphQL na javnem robu z gRPC med backend mikrostoritvami — in poimenuje konkretne kompromise (tveganja predpomnjenja in `N+1` pri GraphQL, šibka zgodba gRPC z brskalniki). Prav to sklepanje o ustreznosti in ceni, ne pa sposobnost recitiranja funkcij, je signal.

Trije na hitro

REST

GraphQL

gRPC

Kako izbrati

Zakaj je to pomembno

Povezana vprašanja