REST czy GraphQL: jaki styl API wybrać?
REST i GraphQL rozwiązują ten sam podstawowy problem – pozwalają klientowi pobierać dane z serwera przez HTTP – ale robią to przy innych kompromisach, a wybór między nimi bywa traktowany bardziej ideologicznie, niż to konieczne. Żadne z tych podejść nie jest po prostu lepsze. Każde lepiej pasuje do innego rodzaju produktu i zespołu.
Jak działa REST i gdzie się sprawdza
REST organizuje API wokół zasobów – osobny URL dla użytkownika, dla zamówienia, dla listy produktów – i standardowych metod HTTP (GET, POST, PUT, DELETE), które na tych zasobach operują. To domyślne podejście do API webowych od tak dawna, że narzędzia, mechanizmy cache'owania i znajomość tematu w zespołach są w pełni dojrzałe. Każdy cache HTTP, każdy CDN i każda przeglądarka już wiedzą, jak buforować żądanie GET na podstawie adresu URL – to realna, praktyczna przewaga, którą REST dostaje za darmo.
REST robi się niewygodny, gdy klient potrzebuje danych z kilku zasobów naraz. Ekran aplikacji mobilnej, który wyświetla profil użytkownika, jego pięć ostatnich zamówień i pozycje każdego z nich, może wymagać trzech czy czterech osobnych wywołań REST albo specjalnego, zbiorczego endpointu zbudowanego wyłącznie dla tego ekranu – który potem trzeba utrzymywać razem z każdym innym endpointem „pod ekran”, w miarę jak produkt się rozrasta.
Jak działa GraphQL i gdzie się sprawdza
GraphQL odwraca ten model: zamiast serwera decydującego, jaki kształt danych zwraca każdy endpoint, klient wysyła zapytanie opisujące dokładnie te pola, których potrzebuje – potencjalnie z wielu powiązanych zasobów – i dostaje dokładnie to, ani mniej, ani więcej. Ta elastyczność w ramach jednego żądania to główna zaleta GraphQL i jest naprawdę cenna w produktach z wieloma różnymi ekranami lub aplikacjami klienckimi (web, iOS, Android), z których każda potrzebuje nieco innego wycinka tych samych danych. Jeden elastyczny schemat może obsłużyć je wszystkie bez mnożenia niestandardowych endpointów.
Kompromisy też są realne. Cache'owanie jest trudniejsze, bo API GraphQL to zwykle jeden endpoint POST, a nie wiele adresów GET, które da się buforować – potrzebne są więc wyspecjalizowane mechanizmy (persisted queries, znormalizowane cache po stronie klienta, takie jak Apollo czy Relay) zamiast standardowego cache'owania HTTP. Złożonością zapytań trzeba aktywnie zarządzać po stronie serwera, bo klient może technicznie poprosić o głęboko zagnieżdżone, kosztowne zapytanie, na które prosty endpoint REST nigdy by nie pozwolił. Do tego krzywa uczenia się dla zespołu, który dopiero zaczyna – projektowanie schematu, resolvery, narzędzia po stronie klienta – jest bardziej stroma niż w przypadku REST.
Praktyczna decyzja
- Wybierzcie REST, jeśli macie prostszy model danych i niewiele typów klientów, chcecie opierać się na standardowym cache'owaniu i narzędziach HTTP albo wasz zespół już dobrze zna REST, a produkt nie wymaga niczego więcej.
- Wybierzcie GraphQL, jeśli obsługujecie z jednego backendu kilka bardzo różnych aplikacji klienckich, wasz model danych jest naprawdę relacyjny i klienci często muszą przechodzić po tych relacjach w jednym żądaniu albo pobieranie zbyt wielu lub zbyt małej ilości danych przez REST (over-fetching i under-fetching) stało się realnym, powracającym problemem, a nie hipotetycznym.
- Żadne z nich nie musi być wyborem „wszystko albo nic” dla całego systemu – wiele realnych produktów korzysta z REST w prostych usługach CRUD i z GraphQL jako warstwy agregującej przed nimi dla zapytań klienckich, albo odwrotnie.
Co ma większe znaczenie niż styl API
Niezależnie od wyboru o tym, czy z API będzie się wygodnie pracować w dłuższej perspektywie, decydują te same rzeczy: jasne, spójne nazewnictwo, porządna obsługa błędów zamiast zwracania kodu 200 na wszystko, sensowna paginacja i dokumentacja, która jest na bieżąco aktualizowana. Dobrze zaprojektowane API REST zawsze wygra ze źle zaprojektowanym API GraphQL – i odwrotnie. Format ma dużo mniejsze znaczenie niż dyscyplina, która za nim stoi.
Dobór architektury API do rzeczywistego charakteru produktu – a nie po prostu modniejszej opcji – to część pracy nad oprogramowaniem i aplikacjami webowymi, którą wykonujemy w Burncode przy każdym budowanym backendzie. Zła decyzja w tej kwestii jest kosztowna do odkręcenia, gdy zależy od niej już kilkanaście aplikacji klienckich.