GraphQL to nowy standard API, bardziej elastyczny i wydajny w stosunku do REST. 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.
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]

– Brak Overfetchingu i Underfetchingu

– Elastyczne API

– Analiza zapytań i optymalizacja API

– Monitoring wydajności (redukcja wąskich gardeł)

Podstawy GraphQL

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

– Schema Definition Language (SDL) czyli model API: Int, Float, String, Boolean, ID

– Queries

– Mutations

– Subscriptions

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”.

Kolejna strategia opierająca się na ustalaniu złożoności zapytań to Query Complexity-opiera się ona na przypisaniu do każdego pola stopnia złożoności za pomocą liczby (każda skalarna wartość ma przypisaną określoną wagę). Gdy ustalona wartość zostanie przekroczona to serwer przestanie wykonywać zapytanie. Pozwala to ograniczyć zapytania (i podzapytania) z maksymalną złożonością.

Prelegent:


Wojciech Kloc

Java Developer z 15-letnim doświadczeniem. Ubrudził ręce w kilku językach programowania i wpuścił na produkcję niejednego buga. Entuzjasta czystego kodu, miłośnik wygodnego życia, majsterkowicz, ogrodnik i turysta motocyklowy. Lubi podejmować nowe wyzwania i z ciekawością obserwuje zmieniający się świat technologii. Wyznaje zasadę, że przede wszystkim liczy się jakość.