GraphQL to ciekawostka w cv czy must have?

Pracując w web developmencie trzeba wiedzieć, czym jest api REST’owe. W końcu znaczna część web API jest pisana w tym interfejsie. Prosty schemat dostępu do zasobów, gdzie jeden endpoint, to jeden rodzaj zasobu. Potrzebujemy dostać się do produktów? Wystarczy wejść na /products. Potrzebujemy specyficznego produktu? Całkiem logiczne więc będzie, że powinniśmy odpytać /products/:id. 

Logicznie zbudowany schemat, dzięki któremu w teorii nie powinniśmy potrzebować dokumentacji, by być w stanie połapać się, co gdzie jest (niestety, jak jest w praktyce, każdy wie). Problem zaczyna się, gdy potrzebujemy wielu różnych obiektów. Musimy wtedy dla każdego typu obiektów zrobić oddzielne zapytanie, co bardzo mocno może spowolnić działanie naszej aplikacji. Gdyby tylko dało się poprosić o wszystkie potrzebne obiekty i ich zależności jednym zapytaniem… a no da się, od tego jest graphQL.

Czym jest graphQL?

Zanim odpowiemy sobie na pytanie z tytułu, wyjaśnijmy, czym dokładnie jest graphQL i jak takie API powinno wyglądać i się zachowywać.

Dzięki temu schematowi możemy w jednym zapytaniu dostać wszystkie informacje, które są nam potrzebne, a co i równie ważne, tylko te informacje, które są nam potrzebne. Jako że najłatwiej zawsze poznawać rzeczy w praktyce, zróbmy małe porównanie, REST vs GraphQL. Wróćmy do API naszego sklepu. Potrzebujemy pobrać wszystkie zamówienia, dla każdego zamówienia musimy jeszcze pobrać listę nazw przedmiotów, np. do wyświetlania w liście na naszej stronie. W REST’owym schemacie zapytania wyglądałyby tak:

/orders

Takie zapytanie zwróci nam np. 100 zamówień dla każdego zamówienia musimy wykonać jeszcze:

/orders/:id/order_items

dostajemy w odpowiedzi listę całych obiektów order_item, a potrzebujemy z nich tylko pole name.

Jeśli założymy, że mamy 100 zamówień i każde z nich ma 1 przedmiot, wyjdzie nam łączna ilość 101 zapytań. Dzięki GraphQL’owi liczbę tą można zredukować do 1!

W API stworzonym według zasad GraphQL zawsze istnieje tylko jeden endpoint, na który wysyłamy nasze zapytanie.

Takim skonstruowanym zapytaniem, dostaniemy w odpowiedzi listę zamówień oraz dla każdego zamówienia pola name, shipping_address oraz liste order_items z polem name dla każdego przedmiotu. Nawet jeśli obiekty te składają się z większej ilości pól, nie zobaczymy tych informacji w odpowiedzi. Dostaniemy tylko to o co poprosiliśmy.

Mam nadzieje że Ci, którzy nie mieli nigdy styczności z tym rozwiązaniem zostali zaciekawieni i już sięgają po google żeby doczytać więcej. Spokojnie, tutaj macie wszystko: graphql.org. Na stronie tej można znaleźć świetny poradnik wprowadzający, dzięki któremu każdy będzie w stanie załapać zasady od razu!

Oferty pracy z

Kiedy GraphQL jest przydatny?

GraphQL brzmi jak odpowiedź na każde pytanie i lek na całe zło, niestety, jak wszystko na tym świecie, facebookowy język zapytań (Tak, graphQL został wymyślony w laboratoriach facebooka) nie jest bez wad.

Ale zanim zaczniemy sypać minusami, sformalizujemy plusy. Zalety GraphQL to:

• Łatwa skalowalność klienta. Rozbudowując czy zmieniając naszą aplikacje frontendową nie musimy się martwić o zapytania do API. Wystarczy, że dodamy/lekko zmodyfikujemy nasze query.
• Idealny jeśli mamy wiele powiązanych ze sobą zasobów danych. Dzięki GraphQL redukujemy dużą ilość zapytań do API do 1, tak jak w przypadku ze sklepem.
• Perfekcyjny dla urządzeń mobilnych. Cały czas w przypadku tworzenia oprogramowania na urządzenia mobilne musimy martwić się o przepustowość, więc wysyłanie dużej ilości niepotrzebnych danych zabiera nam sporo tego cennego zasobu. Dzięki graphql’owi dostajemy tylko to, co jest nam potrzebne.

Aż ciężko uwierzyć, że po tak mocnych plusach może być jakikolwiek znaczący minus, a jednak… Nie da się ukryć, że jest to rozwiązanie które jest lepsze dla klienta. Wady GraphQL to:

• Backendowe problemy z wydajnością. Przez to, że nie kontrolujemy jakie dane i w jakiej ilości może zażyczyć sobie klient, narażamy się na problemy wydajnościowe. Jeśli użytkownik zażyczy sobie nagle na raz całą bazę danych, to zaczyna robić się mały problem.
• Obsługa błędów. Nie oszukujmy się, REST’owe kody statusów to jednak z najlepszych rzeczy na (programistycznym) świecie. Bez patrzenia do środka odpowiedzi jesteśmy wstanie dowiedzieć się, czy nie obyło się bez błędów, a jeśli coś się stało to bez problemu dowiemy się co, po samych liczbach. W graphQL’u tego nie doświadczymy i niestety będziemy musieli przejrzeć odpowiedź żeby dowiedzieć się, co zrobiliśmy nie tak.
• Cache’owanie. Jak wiemy z poprzednich akapitów GraphQL korzysta z jednego endpointa, co bardzo mocno utrudnia implementacje pamięci podręcznej w przeglądarce, w celu uniknięcia pobierania takich samych danych jeszcze raz.
• Złożoność. Niestety, tak jak dla frontu to same przyjemności, tak po stronie backendowej jest bardziej złożone i zupełnie nie nadaje się do tworzenia małych projektów z niewielką różnorodnością danych do pobierania.

To jak z tym CV?

Pora w końcu odpowiedzieć na pytanie przewodnie, czy warto się uczyć GraphQL’a żeby mieć lepsze powodzenie na rynku pracy? Na to pytanie można odpowiedzieć krótko: tak.

Nie ma technologii, która nie uatrakcyjni naszego cv. Wszystko co umiemy i czego się nauczymy jest na plus w oczach naszych przyszłych pracodawców. Na pewno jednak taka odpowiedź nie jest satysfakcjonująca, więc przeanalizujmy sobie rynek pracy. 

Wchodząc na justjoin.it i filtrując oferty bazując na znajomości graphQL’a justjoin.it/?q=GraphQL@skill zobaczymy aż 319 oferty pracy w przeróżnych technologiach, które wymagają GraphQL’a. Zdecydowanie dominują tutaj oferty na JavaScript developerów (215 ofert), ale można znaleźć przeróżne technologie, od .net, przez golang do pythona, nawet ruby się zdarzyło! 

Można zastanawiać się, że prawie 320 ofert na tak dużym rynku, jak IT to nie jest wcale tak dużo, w końcu na justjoin.it jest ich ponad 16 tysięcy! Tylko że jak wpiszemy REST to nagle się robi z tych 16 tysięcy około dwa tysiące ofert. To nadal więcej niż 320, ale dalej w porównaniu do maksymalnej liczby ofert nie jest tak imponująca. Czy to znaczy, że nie trzeba znać REST’a ani GraphQL’a żeby załapać się na pozostale 16 tysięcy ofert pracy? 

Na pewno znaczna część tej liczby to nie oferty na web development, ale najpewniej nie większość, gdy w tym momencie to najpopularniejsza gałąź branży. To znaczy, że po prostu najczęściej pracodawcy nie uwzględniają znajomości poszczególnych schematów komunikacji z API. Logicznym założeniem jest, że jeśli jest ktoś midem/seniorem, to powinien REST’a już znać, a graphQL’a, jeśli jeszcze nie zna, to bardzo szybko poznać i się nauczyć.