GraphQL vs. Rest API w aplikacjach headless eCommerce

Autor Agnieszka Wojtas

Featured image

Jeśli rozważasz wybór odpowiedniego narzędzia do komunikacji między Twoją aplikacją, a serwerem, na pewno natknąłeś się na termin API.

Czym jest API (Application Programming Interface)?

API stanowi zestaw reguł i protokołów umożliwiających efektywną komunikację pomiędzy różnymi aplikacjami. Ten mechanizm precyzyjnie definiuje sposób, w jaki różne składniki oprogramowania powinny ze sobą współpracować, ułatwiając tym samym integrację pomiędzy nimi. W kontekście stron internetowych, API jest często używane do komunikacji między frontendem, a backendem.

Istnieje szereg różnorodnych rodzajów interfejsów programowania aplikacji, a wśród nich można wyróżnić dwa wyjątkowo powszechne przykłady, o których wspomniano w tytule: GraphQL oraz REST API.

Czym są wyróżnione technologie i skąd się wzięły?

GraphQL vs. REST Api.png

REST API, jak i GraphQL, to ogólnodostępne style architektury oprogramowania. Ich głównym celem jest płynna wymiana danych pomiędzy wykorzystywanymi aplikacjami i zintegrowanymi platformami, a serwerem.

Dostarczają one aplikacjom klienckim możliwość korzystania z zasobów serwera oraz manipulacji nimi za pomocą powszechnie stosowanych metod HTTP, takich jak GET, POST, PUT i DELETE. Dzięki nim, możliwe jest wysyłanie różnorodnych zapytań.

REST (Representational State Transfer) API

rest-api-1.svg

W architekturze REST (czasami nazywanej RESTful API), dane są traktowane jako zasoby, a każdy zasób jest identyfikowany unikalnym URI (Uniform Resource Identifier). Na przykład, dla kolekcji użytkowników, URI mogłoby wyglądać tak: /users. Zasoby z kolei są reprezentowane w formie, którą można przesyłać między klientem, a serwerem. Najczęściej stosowanym formatem reprezentacji jest JSON.

REST definiuje pewne podstawowe operacje, które można wykonywać na zasobach. Są to przeważnie operacje typu CRUD (Create, Read, Update, Delete), mapowane na standardowe metody HTTP: POST, GET, PUT, DELETE.

Zalety REST API:

  • Prostota: REST API jest łatwe do zrozumienia i korzystania zarówno dla programistów, jak i klientów.
  • Kompatybilność: Z REST API można korzystać w połączeniu z każdą technologią i w różnych środowiskach programistycznych.
  • Łatwość testowania: REST API jest prosty w testowaniu, ponieważ operacje są zazwyczaj oparte na standardowych metodach HTTP, co ułatwia korzystanie z narzędzi do testowania API.
  • Łatwość cachowania: Ze względu na jednoznaczną identyfikację zasobów i jednoznaczne operacje, wyniki zapytań mogą być łatwo cachowane.
  • Bezstanowość: Brak sesji po stronie serwera ułatwia skalowanie i zarządzanie wieloma request’ami. Po otrzymaniu żądania, serwer nie jest zobowiązany do przechowywania jakichkolwiek informacji związanych z tym konkretnym żądaniem.

Wady REST API:

  • Nadmierna komunikacja: W przypadku zapytań o duże ilości danych, REST może prowadzić do nadmiernego przesyłania informacji, co może znacząco wpływać na wydajność aplikacji.
  • Brak wbudowanych mechanizmów bezpieczeństwa: REST API nie dostarcza wbudowanych mechanizmów bezpieczeństwa, co oznacza, że programiści muszą samodzielnie dbać o aspekty takie jak uwierzytelnianie i autoryzacja.
  • Niewystarczająca dla pewnych zastosowań: Dla niektórych bardziej zaawansowanych przypadków, takich jak np. przesyłanie strumieniowe (streaming) danych, REST może być mniej odpowiedni niż inne architektury.

Przykładowe użycie:

Przy tworzeniu przejrzystej i skutecznej struktury dla aplikacji eCommerce, takiej jak np. marketplace i dedykowanej podstrony sprzedawcy (vendora), potrzebujemy różnorodnych informacji, w tym:

  • danych sprzedającego,
  • produktów danego sprzedającego,
  • opinii klientów,
  • informacji dotyczących zamówień.

W takim wypadku, należałoby stworzyć kilka endpoint’ów:

  • /user/id w celu uzyskania danych o sprzedającym,
  • /user/id/products w celu uzyskania listy produktów danego użytkownika,
  • /user/id/reviews w celu uzyskania opinii,
  • /user/id/orders w celu uzyskania informacji o zrealizowanych zamówieniach, np. ich ilości.
fetch('/user/1234')
 .then(response => response.json())
 .then(data => {
   // Handling the data returned from the API
   console.log(data);
 })
 .catch(error => {
   // Error handling
   console.error('Error while downloading data:', error);
 });

Jednakże, w każdym z tych przypadków otrzymujemy pełny zestaw informacji, nawet tych, które aktualnie nie są nam potrzebne. Można wówczas przekształcić API, aby odpowiadało wymaganiom poszczególnego feature’a lub podstrony, ale w przypadku rozbudowy lub zmian założeń aplikacji, dostosowanie API pod każde zapytanie trwałoby dłużej. To ograniczałoby szybkość dokonywania zmian w aplikacji po stronie frontendu.

GraphQL

GraphQL_Logo.svg.png

GraphQL to powszechna alternatywa dla interfejsów API opartych na REST, szczególnie w przypadku rozwiązań headless eCommerce. To, co jest jeszcze charakterystyczne dla tego rozwiązania to to, że GraphQL korzysta zawsze tylko z jednego endpoint’u.

Zalety GraphQL:

  • Kompatybilność i elastyczność: Z GraphQL można korzystać w połączeniu z każdą technologią, podobnie jak w przypadku REST API.
  • Optymalizacja wydajności: GraphQL minimalizuje zbędne i nieefektywne przesyłanie informacji poprzez pobieranie jedynie niezbędnych danych za pomocą równoległych żądań — zwiększa wydajność sieci oraz ogólne wrażenia użytkownika — innymi słowy, korzystając ze schematów GraphQL dostajemy tylko to, co jest nam potrzebne.
  • Łatwa skalowalność: Rozwijając lub modyfikując aplikację frontendową, nie trzeba się martwić o obsługę zapytań do API. Wystarczy dodać lub delikatnie zmodyfikować zapytanie (query).
  • Redukcja ilości kodu: Redukuje powielanie kodu, co ułatwia jego utrzymanie, usprawnia proces programistyczny i gwarantuje jednolitość.

Wady GraphQL:

  • Cache’owanie: Jeden endpoint bardzo utrudnia implementacje pamięci podręcznej w przeglądarce, w celu uniknięcia ponownego pobierania tych samych danych.
  • Problemy z buforowaniem: Przy zastosowaniu GraphQL mogą pojawić się pewne trudności z buforowaniem, zwłaszcza w przypadku systemów zarządzania treścią (CMS) headless lub aplikacji obsługujących duże i skomplikowane zapytania.
  • Obsługa błędów: Niestety w przypadku tej metody, trzeba przyjrzeć się całej odpowiedzi, aby dowiedzieć się, skąd i dlaczego wystąpił błąd, nie tak jak w przypadku REST API.

Przykładowe użycie:

Odnosząc się do tego samego przykładu, co w poprzedniej metodzie, przy użyciu GraphQL wystarczyłoby skorzystać tylko z jednego endpoint’u. Zapytanie (query) mogłoby wyglądać wówczas następująco:

query {
 user(id: "1234") {
   email
   firstName
   lastName
   products {
     id
     name
     price
   }
   reviews {
     id
     title
     content
   }
   orders {
     count
   }
 }
}

Otrzymalibyśmy informacje o danym użytkowniku, jego produktach, opiniach itd. z uwzględnieniem jedynie wymaganych parametrów.

Podsumowanie: W jakich przypadkach sprawdzą się opisane metody?

GraphQL doskonale sprawdzi się w aplikacji, która wymaga zróżnicowanych danych na poszczególnych stronach i złożonych możliwości zapytań.

Niemniej jednak, w przypadku obsługi dużej ilości danych, korzystniejsze może okazać się zastosowanie REST API. Wynika to z faktu, że czasami złożone zapytania GraphQL mogą wprowadzać opóźnienia, zwłaszcza w porównaniu do zapytań do kilku endpointów REST API. Ponadto, niezaprzeczalnym atutem jest łatwość, bezstanowość oraz stabilne zarządzanie danymi, a także szybkość tworzenia REST API, co czyni je atrakcyjnym wyborem, szczególnie dla mniejszych aplikacji.

Podsumowując, GraphQL i REST API to dwie różne metody budowania interfejsów programistycznych, a z każdą z nich wiążą się swoje zalety i wady. GraphQL daje większą elastyczność w wyszukiwaniu i pobieraniu danych, natomiast REST jest bardziej prosty i ułatwia buforowanie. Kluczowe znaczenie ma jednak ocena konkretnych wymagań oraz wyzwań, aby określić, która z metod jest właściwym wyborem dla naszej aplikacji headless eCommerce. Niemniej jednak, należy pamiętać, że nie jest wykluczone współistnienie obu tych rozwiązań w projekcie! 🤓

Inne posty na blogu

Maintance mode w aplikacjach Next.js

Jak zaimplementować maintenance mode w Next.js? Czy jest to równie proste, co kilkuminutowa konfiguracja wtyczki w WordPress’ie? Oczywiście, że tak!

Medusa vs Magento: Całkowity koszt posiadania

Magento, w porównaniu do Medusy, może prowadzić do wyższych kosztów długoterminowych z powodu swojej licencji oraz ryzyka związanego ze stopniowym spadkiem popularności języka PHP...

Opowiedz nam o swoim projekcie

Myślisz o nowym projekcie? Zrealizujmy go!

Naciskając „Wyślij wiadomość” udzielasz nam, tj. Rigby, zgody na email marketing naszych usług w ramach komunikacji dotyczącej Twojego projektu. Zgodę możesz wycofać, np. pisząc na adres hello@rigbyjs.com.
Więcej
placeholder

Grzegorz Tomaka

Co-CEO & Co-founder

LinkedIn icon
placeholder

Jakub Zbaski

Co-CEO & Co-founder

LinkedIn icon