REST vs GraphQL vs gRPC — mikor választanád melyiket?

Question

IT Interview Practice · Accepted Answer

Ez három különböző API-paradigma, mindegyik más megkötésekre optimalizálva. Nincs egyetemes győztes — a helyes választás a **felhasználótól, az adat alakjától és a hálózattól** függ.

## A három egy pillantásra

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

Erőforrás-orientált, sima HTTP fölött. **Válaszd** publikus API-khoz, CRUD-szolgáltatásokhoz, és bármihez, ami profitál a HTTP caching-ből, a mindenütt-jelenlévőségből és az egyszerűségből. Gyengeségei az **over-fetching** (megkapod az egész `/users/42`-t, még ha csak egy mezőre van szükséged is) és az **under-fetching** (az `N+1` probléma: lekérsz egy usert, majd ciklusban lekérsz minden ordert).

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

## GraphQL

Egyetlen endpoint, ahol a **kliens pontosan megadja, mit akar** egyetlen query-ben, megoldva az over/under-fetchinget. **Válaszd** gazdag frontendekhez (különösen mobilra, ahol a round tripek költségesek), és amikor sok kliensnek ugyanazon adat különböző alakjaira van szüksége.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
Kompromisszumok: a HTTP caching nehezebb (minden egy `POST` a `/graphql`-ra), és egy naiv resolver elrejthet költséges `N+1` adatbázis-lekérdezéseket.

## gRPC

Contract-first RPC, **Protobuf**-fal **HTTP/2** fölött. Bináris és multiplexelt, így gyors és kompakt, streaming-támogatással. **Válaszd** **belső service-to-service** kommunikációhoz egy mikroszolgáltatás-backendben, ahol a teljesítmény és a szigorú típusosság számít. Gyengeség: gyenge böngészőtámogatás (proxy kell, mint a grpc-web), és nem ember által olvasható.

## Hogyan válassz

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

## Miért fontos

Senior szinten az interjúztatókat kevésbé érdeklik a definíciók, inkább az, hogy tudsz-e **egy választást megkötések alapján megindokolni** — ez a kérdés valójában az, hogy "egy technológiát egy problémához tudsz-e illeszteni, ahelyett, hogy a hype-ot kergetnéd?". A legerősebb válaszok arra a fájdalomra horgonyoznak, amelyet mindegyik megold: a GraphQL azért létezik, hogy megölje az over/under-fetchinget az igényes frontendek számára, a gRPC azért létezik, hogy a belső service-hívásokat gyorssá és szigorúan típusossá tegye, a REST pedig az alapértelmezett marad, mert a HTTP caching, a tooling és az egyetemes ismertség hatalmas gyakorlati előnyök a publikus és CRUD-stílusú API-khoz. Kulcsfontosságú, hogy egy senior mérnök megjegyzi: ez **nem vagy-vagy** — egy gyakori architektúra REST vagy GraphQL a publikus szélen, gRPC-vel a backend-mikroszolgáltatások között —, és megnevezi a konkrét kompromisszumokat (a GraphQL caching- és `N+1`-kockázatai, a gRPC gyenge böngészőtörténete). Ez az illeszkedésről és költségről való gondolkodás, nem a funkciók felmondásának képessége, a jel.

A három egy pillantásra

REST

GraphQL

gRPC

Hogyan válassz

Miért fontos

Kapcsolódó kérdések