GraphQL vs REST: Wszystko, co musisz wiedzieć

Wybór technologii, które zostaną uwzględnione w stosie technologicznym następnego projektu, może być trudny. W wielu przypadkach — a zwłaszcza jeśli chodzi o wybór między interfejsami API GraphQL i RESTful — chodzi o wybór następnej najlepszej architektury projektowania interfejsu API.

Istnieją cztery ważne sposoby tworzenia interfejsów API: SOAP, GRPC, REST i GraphQL. Często zawężamy nasze myśli do REST i GraphQL, gdy chcemy budować API. Dzieje się tak, ponieważ REST zmienił tradycyjne sposoby budowania interfejsów API za pomocą SOAP i GRPC.

GraphQL jest powszechnie oznaczany jako lepszy REST, ponieważ reprezentuje lepszy sposób budowania interfejsów API. Wielu programistów wierzy, że GraphQL zastąpi REST. O wiele więcej osób już odkryło, że GraphQL pomaga rozwiązać niektóre typowe wyzwania, przed którymi stają programiści podczas tworzenia interfejsów API REST.

Te dwie metody budowania interfejsów API są całkowicie różne. W praktyce technologie te działają poprzez wysyłanie żądania HTTP i odbieranie wyniku. Obie mają swoje wady i zalety, a w tym artykule szczegółowo omówimy te dwie wspaniałe technologie, które zmieniły sposób opracowywania i skalowania interfejsów API.

Zanim jednak zagłębimy się w szczegóły, najpierw zbadajmy znaczenie interfejsów API GraphQL i RESTful.

Co to jest GraphQL?

GraphQL to język zapytań API, a także środowisko wykonawcze do odpowiadania na te zapytania przy użyciu istniejących danych. Jest również wyposażony w potężne narzędzia do obsługi nawet najbardziej złożonych zapytań.

Główną cechą GraphQL jest możliwość żądania i otrzymywania tylko określonych żądanych danych — nic więcej. To znacznie ułatwia skalowanie interfejsów API wraz z aplikacją.

Najbardziej ekscytującą częścią GraphQL jest możliwość dostarczenia wszystkich danych w jednym punkcie końcowym.

Powyższy diagram jest typową reprezentacją architektury GraphQL. Klienci składają żądania z różnych urządzeń, a GraphQL obsługuje ich żądania i zwraca tylko żądane dane. To zgrabnie rozwiązuje problem nadmiernego i niedostatecznego pobierania w interfejsach API RESTful.

W powyższym przykładzie pokazujemy plac zabaw GraphQL i sposób, w jaki można wysyłać zapytania o dane z jednym punktem końcowym. Na górze znajduje się punkt końcowy API, po lewej zapytanie żądające nazwy kontynentów, a na końcu po prawej odpowiadamy na zapytanie, które zażądaliśmy.

GraphQL został stworzony przez Facebooka, głównie w celu rozwiązania doświadczeń deweloperów aplikacji mobilnych podczas pracy z interfejsami API REST. Od czasu wydania pierwszej wersji open-source w 2015 roku, GraphQL doświadczył ogromnego wzrostu dzięki przyjęciu technologii przez dużych graczy w branży technologicznej.

Firmy korzystające z GraphQL

Poniżej znajduje się lista tylko niektórych firm i aplikacji korzystających aktywnie z GraphQL na swoich serwerach.

Facebook

Facebook stworzył GraphQL i używa go w produkcji, aby zasilać swoje aplikacje mobilne od 2012 roku. Wielomiliardowa firma sieci społecznościowej udostępniła specyfikację GraphQL w 2015 roku, dzięki czemu jest dostępna w wielu środowiskach i zespołach każdej wielkości .

GitHub

GitHub ogłasza również użycie GraphQL, udostępniając GraphQL API do tworzenia integracji, pobierania danych i automatyzacji przepływów pracy przy użyciu GitHub GraphQL API. Interfejs API GitHub GraphQL oferuje bardziej precyzyjne i elastyczne zapytania niż interfejs API GitHub REST.

Pinterest

Pinterest jest również jednym z pierwszych użytkowników GraphQL. Gigant zajmujący się udostępnianiem zdjęć publicznie omówił swoją wczesną eksplorację GraphQL i sposób, w jaki wykorzystują technologię GraphQL, która napędza ich miliardową firmę.

Wiele innych firm wartych miliardy dolarów, takich jak Intuit, Shopify, Coursera i Airbnb, zasila swoje aplikacje za pomocą GraphQL. A ta szeroko zakrojona preferencja dla REST wciąż rośnie.

Co to jest RESTful API?

REST to skrót od „Representational State Transfer”, który jest stylem architektury oprogramowania dla rozproszonych systemów hipermedialnych. Definiuje zasady i ograniczenia wymiany zasobów między serwerem a klientami.

Jeśli te zasady są przestrzegane w interfejsie API, aplikacja tego interfejsu API jest określana jako „RESTful”. Najlepszym tego przykładem jest WordPress REST API.

Poniżej przedstawiono niektóre zasady i ograniczenia, które musi spełniać interfejs API, aby można go było nazywać interfejsem Restful API:

• Oddzielenie klient-serwer: klienci (frontend) i serwer (backend) są całkowicie oddzielne i mogą komunikować się tylko przez punkty końcowe.
• Jednolity interfejs: dane widoczne w interfejsie są identyczne na wszystkich urządzeniach.
• Bezstanowość: serwer nie pamięta, czy bieżące żądanie jest wysyłane po raz pierwszy, czy nie. Każdorazowo zgłaszane żądanie musi zawierać wszystkie informacje niezbędne do przetworzenia go od podstaw.
• Możliwość buforowania : buforowanie i przechowywanie sesji jest dozwolone, ale muszą być skonfigurowane, aby umożliwić użytkownikom końcowym rezygnację z buforowania danych.
• Warstwowa architektura systemu: interfejsy API muszą być zaprojektowane tak, aby ani klient, ani serwer nie mogli stwierdzić, czy komunikują się bezpośrednio, czy przez pośrednika.

Poniższy diagram przedstawia podstawową architekturę REST. Pokazuje, jak zwykle obsługiwane są żądania i odpowiedzi.

Korzyści z GraphQL

Poniżej przedstawiamy kilka korzyści płynących z używania GraphQL, które ilustrują, dlaczego jest to więcej niż wystarczające do zbudowania kolejnej aplikacji wartej miliard dolarów.

Pobieranie danych za pośrednictwem jednego punktu końcowego interfejsu API

Największą zaletą GraphQL jest możliwość dostępu do dowolnego lub wszystkich punktów danych za pośrednictwem pojedynczego punktu końcowego API.

Jednym z najczęstszych problemów z interfejsami API RESTful jest zbyt duża liczba punktów końcowych, aby uzyskać dostęp do informacji. W GraphQL masz tylko jeden punkt końcowy, więc nie musisz wysyłać wielu żądań, aby pobrać różne informacje o obiekcie.

Poniższy diagram przedstawia jasny przykład pobierania zasobów za pomocą RESTful API i GraphQL. Widać, że jest tylko jeden punkt końcowy, aby uzyskać dostęp do zasobu na serwerze GraphQL, podczas gdy wiele punktów końcowych API jest potrzebnych do uzyskania dostępu do różnych zasobów w RESTful API.

Brak nadmiernego lub niedostatecznego pobierania

Problem nadmiernego lub niedostatecznego pobierania jest znanym problemem z interfejsami API RESTful. Dzieje się tak, gdy klienci pobierają dane, trafiając do punktów końcowych, które zwracają stałe struktury danych, lub pobierają mniej lub więcej niż oczekiwali.

Nadmierne pobieranie powoduje, że żądanie otrzymuje — lub „pobiera” — więcej danych, niż jest wymagane przez dane żądanie. Wyobraź sobie, że pobierasz wszystkich użytkowników w tabeli z zamiarem wyświetlenia ich nazw użytkowników na Twojej stronie głównej. W takim przypadku nadmierne pobieranie zwróci wszystkie dane każdego użytkownika, w tym (ale nie tylko) nazwę.

Niepełne pobieranie jest stosunkowo rzadkie, ale zdarza się, gdy określony punkt końcowy nie dostarcza wszystkich żądanych informacji. W razie potrzeby klient będzie musiał złożyć dodatkowe prośby o dostęp do innych informacji.

GraphQL skutecznie rozwiązuje problem nadmiernego lub niedostatecznego pobierania danych, pobierając dokładnie ten zasób, którego zażądał klient, bez żadnych dodatkowych szczegółów.

Lepsza obsługa złożonych systemów i mikrousług

GraphQL może ujednolicić i ukryć złożoność zintegrowanych wielu systemów.

Załóżmy na przykład, że chcemy przeprowadzić migrację z monolitycznej aplikacji zaplecza do architektury mikrousług. Interfejs API GraphQL pomaga obsługiwać komunikację między różnymi mikrousługami, łącząc je w jeden schemat GraphQL.

Po zdefiniowaniu tych schematów zarówno frontend, jak i backend mogą komunikować się oddzielnie bez żadnych dalszych zmian, ponieważ frontend wie, że dane w schemacie będą zawsze zsynchronizowane w całym systemie.

Szybki i bezpieczny

Problem nadmiernego pobierania może powodować większe zużycie przepustowości przez klientów, co z czasem może powodować opóźnienia w aplikacji. Korzystanie z wzorców projektowych RESTful API jest bardziej czasochłonne, aby uporządkować potrzebne informacje z ogromnego ładunku.

Ze względu na zdolność GraphQL do unikania nadmiernego i niedostatecznego pobierania, serwer zwraca bezpieczny, łatwy do odczytania i przewidywalny kształt, który przyspiesza żądania i odpowiedzi API.

Korzyści z REST

Pomimo rosnącej popularności GraphQL, REST jest nadal jednym z najpopularniejszych standardów API. Zobaczmy dlaczego.

• Krzywa uczenia się: interfejsy API RESTful są najłatwiejsze do opanowania i zrozumienia. Jest to jego podstawowa przewaga nad innymi API.
• Serializacja: REST zawiera elastyczne podejście i formaty do serializacji danych w formacie JSON.
• Buforowanie: REST API może zarządzać dużym obciążeniem za pomocą serwera proxy HTTP i pamięci podręcznej.
• Złożone żądanie: interfejsy API REST mają oddzielny punkt końcowy dla różnych żądań, co ułatwia zarządzanie złożonym żądaniem niż w przypadku innych interfejsów API
• Czyste i proste: interfejsy API REST są eleganckie, proste i czyste. Są proste do zbadania.
• Standardowe procedury HTTP: REST używa standardowych wywołań procedur HTTP do pobierania danych i wysyłania żądań.
• Klient/Serwer: Oznacza to, że jego logika biznesowa jest oddzielona od prezentacji. Możesz więc zmienić jedno bez wpływu na drugie.
• REST jest bezstanowy: Wszystkie wiadomości wymieniane między klientem a serwerem mają cały kontekst potrzebny, aby wiedzieć, co zrobić z wiadomością.

Wady GraphQL

Teraz, gdy omówiliśmy zalety GraphQL vs REST, przyjrzyjmy się niektórym wadom GraphQL:

• Trudna krzywa uczenia się: GraphQL nie jest tak łatwa do nauczenia jak REST. Najtrudniejszą częścią budowania GraphQL API jest zaprojektowanie schematu. Zajmuje to dużo czasu i wiedzy domenowej.
• Przesyłanie plików: GraphQL nie posiada natywnej funkcji przesyłania plików. Można to obejść za pomocą kodowania Base64, ale koszt kodowania i dekodowania w ten sposób może być czasochłonny i drogi.
• Buforowanie sieci Web: Buforowanie pomaga zredukować częsty ruch na serwerze, co przyspiesza żądania i proces odpowiedzi dzięki utrzymywaniu często używanych informacji w pobliżu serwera. GraphQL nie obsługuje ani nie polega na metodach buforowania HTTP, w zależności od mechanizmów buforowania klientów Apollo lub Relay.
• Nieodpowiedni dla małych aplikacji: GraphQL może nie być najlepszą architekturą API do tworzenia małych aplikacji. Jeśli Twoja aplikacja nie wymaga bardziej elastycznych zapytań oferowanych przez GraphQL, REST jest drogą do zrobienia.
• Złożony problem z zapytaniami: Zdolność GraphQL do zapewnienia klientowi dokładnie tego, czego chce, może również prowadzić do problemów z propagacją zapytań. Jeśli klient prześle zbyt wiele zagnieżdżonych zapytań, może to prowadzić do wysłania błędnych zapytań, co może być bardzo czasochłonne dla serwera. Lepiej jest używać REST z niestandardowymi punktami końcowymi, aby spełnić takie żądania.

Wady REST

Zwróćmy teraz uwagę na niektóre wady REST:

• Wiele podróży w obie strony: Największym problemem z interfejsami API REST jest natura wielu punktów końcowych. Oznacza to, że klient, aby uzyskać wszystkie zasoby dla kompletnej aplikacji, musi wykonać niezliczone podróże w obie strony, aby uzyskać dane.
• Nadmierne pobieranie i niedostateczne pobieranie: Problem nadmiernego i niedostatecznego pobierania jest główną wadą RESTful APIS. Może powodować opóźnienia w odpowiedziach z powodu pobierania dużych niechcianych ładunków.
• Hierarchia: Ponieważ interfejsy API REST są zbudowane na zasobach odwołujących się do identyfikatora URI, słabo pasują do zasobów, które nie są naturalnie zorganizowane ani dostępne w prostej hierarchii.

Dlaczego warto używać GraphQL zamiast REST

Następnie omówimy, dlaczego warto rozważyć GraphQL do przyszłego rozwoju API zamiast RESTful API.

Silnie typizowany schemat

GraphQL używa silnego systemu typów do definiowania możliwości API. W GraphQL język definicji schematu (SDL) jest używany do definiowania parametrów otaczających sposób, w jaki klient uzyskuje dostęp do danych serwera. Wszystkie interfejsy API udostępnione klientowi są zapisywane w SDL, co rozwiązuje problem niespójności danych widoczny w interfejsach API RESTful.

Brak nadmiernego lub niedostatecznego pobierania

Problem nadmiernego lub niedostatecznego pobierania jest znanym problemem z interfejsami API RESTful, w których klienci otrzymują więcej lub mniej informacji niż żądali. GraphQL rozwiązuje ten problem, dostarczając klientowi medium, na którym może określić potrzebne informacje, a następnie zwracając dokładnie – i tylko – te konkretne informacje.

Wiele punktów końcowych

Jednym z największych problemów RESTful API jest posiadanie zbyt wielu punktów końcowych, aby uzyskać dostęp do informacji.

Załóżmy, że chcesz uzyskać dostęp do konkretnego użytkownika poprzez jego numer identyfikacyjny. Zostanie wyświetlony punkt końcowy, taki jak /users/1 . Ale jeśli chcesz uzyskać dostęp do zdjęć tego użytkownika, musisz wysłać żądanie do innego punktu końcowego, takiego jak /users/1/photos .

W GraphQL masz jeden punkt końcowy i nie musisz wysyłać wielu żądań, aby pobrać różne informacje o użytkowniku.

GraphQL vs REST Showdown

Na koniec zbadamy główną różnicę między interfejsami API GraphQL i RESTful. Następnie omówimy niektóre cechy dobrego projektu API i porównamy, w jaki sposób obsługuje je każda technologia.

Wydajność

Nie ma wątpliwości, że GraphQL działa szybciej niż RESTful API ze względu na możliwość zapewnienia pojedynczego punktu końcowego, aby uzyskać dostęp do wszystkich zasobów. Interfejsy API RESTful korzystają z wielu punktów końcowych, co może powodować opóźnienia w sieci.

Złożoność zapytań

Ponieważ punkty końcowe nie są podzielone na wiele punktów końcowych, zapytania GraphQL mogą z czasem stać się coraz bardziej złożone. Z drugiej strony punkty końcowe API RESTful są oddzielone, co ogranicza API RESTful do prostych zapytań.

Popularność i wsparcie społeczności

GraphQL to rozwijający się wzorzec architektury API i język zapytań. Chociaż jest jeszcze młody, tempo jego przyjmowania i pula zasobów szybko rosną, a zasoby już obfitują dla osób zainteresowanych nauką tego dla siebie.

Z drugiej strony REST już może pochwalić się ogromnym wsparciem społeczności i nadal jest używany przez wszelkiego rodzaju firmy, od budujących małe mikroserwisy po te, które tworzą złożone aplikacje społecznościowe i nie tylko.

Obecnie konkurs popularności pomiędzy GraphQL a REST jest remisem. Obie technologie są nadal szeroko stosowane i wspierane przez społeczność programistów.

Krzywa uczenia się

Krzywa uczenia się dla GraphQL jest stroma. Wymaga dobrej znajomości domeny z zakresu programowania API i ogólnej inżynierii oprogramowania. Całkowicie początkujący będzie miał trudności ze zrozumieniem GraphQL na tyle dobrze, aby zbudować złożoną aplikację.

I odwrotnie, REST jest bardzo łatwy do rozpoczęcia i wymaga mniej wiedzy o domenie poza bramą. RESTful API jest dobrze zintegrowany z większością głównych języków programowania i popularnych frameworków, dzięki czemu nauka jest bardzo łatwa.

Streszczenie

GraphQL to nowa technologia, która podąża śladami architektonicznych wzorców RESTful API, podobnie jak REST został wprowadzony do rozwiązywania problemów z wzorcami SOAP API.

GraphQL oferuje szybsze odpowiedzi, pojedynczy punkt końcowy API dla wszystkich zapytań oraz ścisły schemat zapewniający spójny dostęp do danych. Te powody sprawiły, że wielomiliardowe firmy zaczęły przechodzić na GraphQL, nawet na wczesnym etapie. Jednak pomimo swoich ograniczeń, protoplasta GraphQL, REST, nadal utrzymuje silną pozycję na scenie.

W tym przewodniku omówiliśmy wszystko, co musisz wiedzieć o GraphQL i interfejsach API RESTful, w tym zalety i wady każdej technologii, aby pomóc Ci pewnie zdecydować, którą preferujesz. Omówiliśmy również znane problemy z interfejsami API RESTful — takie jak nadmierne pobieranie, niedostateczne pobieranie i wiele punktów końcowych — oraz sposób, w jaki GraphQL próbuje rozwiązać te problemy i zwiększyć wydajność aplikacji.

Masz teraz wystarczający wgląd, aby wybrać, czy GraphQL vs REST jest odpowiedni dla Twojego następnego projektu. Daj nam znać w sekcji komentarzy, co będziesz budować z wybranym zwycięzcą!