Jak to działa

REST czy GraphQL — bez świętej wojny

5 sierpnia 2026 2 min czytania web-pc.pl 9 komentarzy

Jedno API oddaje dane w stałych porcjach, drugie pozwala klientowi zamówić dokładnie to, czego potrzebuje. Oba podejścia mają sens, tylko w innych sytuacjach.

REST czy GraphQL — bez świętej wojny

Dyskusja o tym, co lepsze, ciągnie się od lat i zwykle mija się z celem — bo to narzędzia do trochę innych zadań. Warto wiedzieć, na czym polega różnica, zanim się wybierze.

REST: stałe adresy, stałe porcje

Każdy zasób ma swój adres. Pytasz o użytkownika, dostajesz komplet danych o nim:

GET /api/uzytkownicy/42
GET /api/uzytkownicy/42/zamowienia

Rozwiązanie proste, przewidywalne i doskonale współpracujące z pamięcią podręczną przeglądarki oraz serwerów pośredniczących. Ma jednak dwie typowe bolączki.

Dostajesz za dużo. Potrzebujesz imienia, a serwer wysyła też adres, historię i ustawienia. Na łączu komórkowym to realny koszt.

Albo za mało. Żeby narysować jeden ekran, wykonujesz trzy zapytania po kolei, bo każde zależy od poprzedniego. Przy wolnym łączu każda taka podróż to setki milisekund.

GraphQL: jedno zapytanie, twoja lista

Zamiast wielu adresów jest jeden, a klient opisuje, czego chce:

{
  uzytkownik(id: 42) {
    imie
    zamowienia(ostatnie: 3) {
      numer
      kwota
    }
  }
}

Odpowiedź ma dokładnie ten kształt — ani pola więcej. Jedno wywołanie zamiast trzech, zero danych na zapas. Za tę wygodę płaci się gdzie indziej.

Za co się płaci

  • Trudniejsze buforowanie. W REST adres jednoznacznie identyfikuje odpowiedź, więc cache działa sam. W GraphQL każde zapytanie jest inne i pamięć podręczną trzeba budować samodzielnie.
  • Więcej pracy na starcie. Schemat, typy, mechanizm rozwiązywania pól — zanim cokolwiek zadziała, jest sporo konfiguracji.
  • Ryzyko kosztownych zapytań. Klient może poprosić o dane zagnieżdżone na pięć poziomów i położyć bazę. Trzeba ograniczać złożoność zapytań.
  • Mniej oczywiste monitorowanie. Wszystko idzie jednym adresem, więc statystyki „które API jest wolne" trzeba zbierać inaczej.

Praktycznie

REST wystarcza, gdy masz jednego klienta o znanych potrzebach — stronę, sklep, panel administracyjny. Prostota jest tu realną zaletą, a nie brakiem ambicji.

GraphQL zaczyna się opłacać, gdy tych klientów jest kilku i każdy potrzebuje czegoś innego: aplikacja mobilna chce minimum danych, panel na komputerze chce wszystkiego, a integracja partnera jeszcze czegoś innego.

Wybieraj według liczby różnych klientów, nie według tego, co jest modne w tym roku.

I jedna uwaga z praktyki: w większości projektów, które prowadzimy, dobrze zaprojektowany REST z przemyślanymi adresami załatwia sprawę i pozwala szybciej ruszyć. GraphQL zostaje na moment, w którym naprawdę widać jego przewagę.

Podziel się:

Komentarze (9)

  1. Artur

    Wreszcie tekst, który nie próbuje mnie do niczego nawrócić. Zdanie o wybieraniu według liczby klientów, a nie mody, zapamiętam.

    Odpowiedz
  2. Artur

    Wreszcie tekst, który nie próbuje mnie do niczego nawrócić. Zdanie o wybieraniu według liczby klientów, a nie mody, zapamiętam.

    Odpowiedz
  3. Monika

    Wdrożyliśmy GraphQL do projektu z jedną aplikacją webową. Rok później wróciliśmy do REST, bo utrzymanie było droższe niż zysk.

    Odpowiedz