GraphQL to język zapytań do API stworzony przez Facebook w 2015 r. i otwarty na licencji open-source w 2018 r. Zamiast eksponować wiele endpointów REST (`/users`, `/users/:id/posts`, `/users/:id/posts/:id/comments`), GraphQL udostępnia jeden endpoint, do którego klient wysyła deklaratywne zapytanie opisujące dokładnie żądane pola w głąb. Serwer zwraca JSON ściśle zgodny z żądanym kształtem — ani więcej, ani mniej. Wszystko opiera się na typowanym schemacie (typy, enumy, relacje) zdefiniowanym po stronie serwera, który służy jednocześnie jako dokumentacja, kontrakt klient/serwer i baza autouzupełniania w IDE.
Sweet spot GraphQL to przeciwieństwo ograniczeń API REST: koniec z over-fetchingiem (pobierać 30 pól, żeby wyświetlić 3) i under-fetchingiem (łączyć 5 wywołań REST, by zrekonstruować widok). W aplikacji mobilnej lub złożonym UI z mocno powiązanymi encjami (e-commerce z produktami/wariantami/opiniami/stanami, dashboard analityczny, aplikacja społecznościowa) GraphQL drastycznie redukuje liczbę roundtripów i pasmo. Po stronie zespołów rozprzęga front od back-endu: front iteruje bez prośby o nowe endpointy do każdego ekranu. Apollo, Relay, Hasura i URQL to dominujące implementacje.
Wada: złożoność serwera (rezolwery N+1, paginacja, cachowanie subtelniejsze niż REST), bezpieczeństwo (bez limitu głębokości/kosztu zapytania klient może wysadzić bazę) i młodsze narzędzia monitoringu. Dla 70% klasycznych SaaS lub oprogramowania biznesowego REST + webhooki jest prostszy i wystarczający. GraphQL nabiera sensu, gdy mają Państwo wielu klientów (web + mobile + partnerzy) na złożonym grafie lub przy BFF agregującym wiele mikroserwisów — często nad architekturą event-driven Kafka.
REST czy GraphQL: jak rozstrzygnąć
- REST domyślnie do prostych publicznych API, integracji B2B, webhooków, wewnętrznych mikroserwisów.
- GraphQL, gdy front konsumuje złożony graf i często zmieniają się ekrany (mobile, dashboard).
- GraphQL do BFF agregującego wiele wewnętrznych API w jedną fasadę dla frontu.
- Nie GraphQL do publicznego API masowego bez solidnego rate-limitingu — ryzyko nieograniczonych kosztownych zapytań.
