REST czy GraphQL — bez świętej wojny
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.
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ę.
Komentarze (9)
-
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 -
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 -
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