REST vs GraphQL vs gRPC — kiedy wybrać każde z nich?

Question

IT Interview Practice · Accepted Answer

To trzy różne paradygmaty API, każdy zoptymalizowany pod inne ograniczenia. Nie ma uniwersalnego zwycięzcy — właściwy wybór zależy od **konsumenta, kształtu danych i sieci**.

## Trzy w skrócie

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

Zorientowany na zasoby na czystym HTTP. **Wybierz go** dla publicznych API, usług CRUD i wszystkiego, co korzysta z cache'owania HTTP, wszechobecności i prostoty. Jego słabości to **over-fetching** (dostajesz całe `/users/42`, nawet jeśli potrzebujesz jednego pola) i **under-fetching** (problem `N+1`: pobierz użytkownika, potem w pętli pobieraj każde zamówienie).

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

## GraphQL

Pojedynczy endpoint, gdzie **klient określa dokładnie, czego chce** w jednym zapytaniu, rozwiązując over/under-fetching. **Wybierz go** dla bogatych frontendów (zwłaszcza mobilnych, gdzie rundy w obie strony są kosztowne) i gdy wielu klientów potrzebuje różnych kształtów tych samych danych.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
Kompromisy: cache'owanie HTTP jest trudniejsze (wszystko to `POST` do `/graphql`), a naiwny resolver może ukryć kosztowne zapytania `N+1` do bazy danych.

## gRPC

RPC oparte na kontrakcie, używające **Protobuf** przez **HTTP/2**. Binarne i multipleksowane, więc szybkie i zwarte, ze wsparciem strumieniowania. **Wybierz go** dla wewnętrznej komunikacji **service-to-service** w backendzie mikrousługowym, gdzie liczy się wydajność i ścisłe typowanie. Słabość: słabe wsparcie przeglądarki (wymaga proxy jak grpc-web) i nieczytelność dla człowieka.

## Wybór

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

## Dlaczego to ważne

Na poziomie senior rozmówcy mniej dbają o definicje, a bardziej o to, czy potrafisz **uzasadnić wybór wobec ograniczeń** — to pytanie tak naprawdę brzmi „czy potrafisz dopasować technologię do problemu, zamiast gonić za hype'em?". Najmocniejsze odpowiedzi zakotwiczają się w bólu, który każde rozwiązuje: GraphQL istnieje, by zabić over/under-fetching dla wymagających frontendów, gRPC istnieje, by uczynić wewnętrzne wywołania usług szybkimi i silnie typowanymi, a REST pozostaje domyślny, bo cache'owanie HTTP, narzędzia i powszechna znajomość to ogromne praktyczne zalety dla publicznych i CRUD-owych API. Co istotne, inżynier senior zauważa, że to **nie „albo-albo"** — częsta architektura to REST lub GraphQL na publicznym brzegu z gRPC między backendowymi mikrousługami — i nazywa konkretne kompromisy (ryzyka cache'owania i `N+1` w GraphQL, słaba historia przeglądarkowa gRPC). To rozumowanie o dopasowaniu i koszcie, a nie umiejętność recytowania funkcji, jest sygnałem.

Trzy w skrócie

REST

GraphQL

gRPC

Wybór

Dlaczego to ważne

Powiązane pytania