BiteIT #66: GraphQL – jako następca RESTA….. czyli czy JSON może być sexy?

O warsztacie:

Podczas webinaru Wojtek prezentuje główny koncept, który stoi za GraphQL. Porównuje go z niekwestionowanym (jeszcze) liderem w komunikacji – RESTem. W trakcie demo pokazujemy jak szybko stworzyć swój pierwszy GraphQL Server (from scratch) i  potestować go za pomocą znanych i lubianych narzędzi.

Obejrzyj nagranie z webinaru:

Co to właściwie jest REST i dlaczego jest taki popularny?

REST API – bezstanowośc [5:43 https://youtu.be/URFETGbiEvo?t=343]. Oznacza to, że każde zapytanie od klienta musi zawierać komplet informacji, oraz że serwer nie przechowuje stanu o sesji użytkownika po swojej stronie. W REST nie istnieją takie pojęcia jak stany czy sesje.

REST działa po http, ma ustalone i czytelne zasady budowania interfejsu oraz zapewnia dobrą separację między klientem a serwerem.

Kiedy REST przestaje być wystarczający, czyli jak to się zaczęło z GraphQL?

Facebook rozpoczął pracę nad GraphQL w 2012 roku z trzech powodów: [6:21 https://youtu.be/URFETGbiEvo?t=381]

Wzrost liczy urządzeń mobilnych, które wymagały wydajnego ładowania danych przy niewystarczającej infrastrukturze telekomunikacyjnej.

Wielość frameworków front-endowych utrudniające budowanie jednolitego interfejsu API.

Rosnące oczekiwania dotyczące CI/CD oraz szybkości iteracji.

Słabe strony REST [11:11 https://youtu.be/URFETGbiEvo?t=671]

Pobieranie danych. Overfetching (nadmiar zwracanych danych, często zupełnie niepotrzebnych). Underfetching i N+1 (potrzeba dopytywania o kolejne poziomy zagłębień)

Silny związek między Front-End i Back End, który w znaczący sposób wpływa na ograniczenie elastyczności w tworzeniu interfejsów

Odpowiedzią na ograniczenia REST API ma być GraphQL API.

W telegraficznym skrócie GraphQL API zajmuje się „zebraniem” wymaganych informacji i wystarcza jeden call do serwera zamiast kilkunastu/ kilkudziesięciu. GraphQL komponuje odpowiedź „behind the scenes” i wysyła ją do urządzenia końcowego.

GraphQL Co to jest?

[17:21 https://youtu.be/URFETGbiEvo?t=1041]

Język zapytań, który umożliwia w sposób dynamiczny i bardzo elastyczny pobierać dane. Serwer GraphQL udostępnia jeden endpoint, który obsługuje zapytania, które możemy definiować wedle potrzeb.

• Nowy standard API, bardziej efektywny i elastyczny w stosunku do REST
• Umożliwia deklaratywne pobieranie danych
• Udostępnia jeden endpoint precyzyjnie odpowiadający na zapytania od klienta

GraphQL benefity

[18:59 https://youtu.be/URFETGbiEvo?t=1139]

Podstawy GraphQL

[23:13 https://youtu.be/URFETGbiEvo?t=1393]

Wszystkie elementy powyżej (root types) łącznie to Schema.

Każde pole każdego typu jest obsługiwane przez funkcję zwaną resolverem [33:48 https://youtu.be/URFETGbiEvo?t=2028]. Resolver to funkcja, która odpowiada za obliczenie wartości każdego żądanego pola. Jeśli pole jest typu skalarnego to zostaje zwrócona jego wartość. Gdy obliczane pole jest obiektem, to zapytanie będzie zawierało kolejne pola, które trzeba rozwiązać. Trwa to iteracyjne aż do osiągnięcia wartości skalarnych.

Live demo

[33:59 https://youtu.be/URFETGbiEvo?t=2139]

• Schema i resolvery 44:04 https://youtu.be/URFETGbiEvo?t=2644
• Generowanie kolekcji (Postman) 50:29 https://youtu.be/URFETGbiEvo?t=3029
• GraphiQL 57:38 https://youtu.be/URFETGbiEvo?t=3458

Bezpieczeństwo GraphQL

[59:03 https://youtu.be/URFETGbiEvo?t=3543]

Ponieważ klienci mają możliwość tworzenia złożonych zapytań, serwery graphQL musza być przygotowane do ich prawidłowej obsługi.

Timeout to najprostsza strategia, która nie wymaga od serwera żadnej wiedzy o przychodzących zapytania. Serwer wie tylko o maksymalnym czasie dozwolonym na zapytanie.

Maximum Query Depth to strategia opierająca się na analizie drzewa składni (AST) zapytania, w wyniku czego serwer GraphQL jest w stanie odrzucić lub zaakceptować żądanie na podstawie jego „głębokości”.