Backend, Frontend

GraphQL to ciekawostka w cv czy must have?

graphql co to

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!

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

Ile GraphQL’a jest na produkcji?

Konkluzja poprzedniego akapitu brzmi: przydatność znania głównego bohatera tej publikacji, nie jest uzależniona od ilości występowania jego nazwy w słowach kluczowych ofert pracy. Więc jak można to sprawdzić? Przede wszystkim sprawdzając, ile dużych marek i aplikacji korzysta z tego rozwiązania. Odwiedzając stronę graphql.org/users widzimy największych użytkowników schematu. Oprócz Mety, która musi używać graphql, bo go stworzyła, wyróżnić możemy takie firmy jak: Audi, AirBnB, WayFair, GitHub, PayPal, Rakuten, Twitter czy Yelp. 

Oprócz nich na stronie widnieje jeszcze aż 90 banerów innych firm! No i śmiało można powiedzieć, że to nie są wszystkie firmy, które korzystają z tego języka zapytań. W internecie można znaleźć informacje, że również Netflix korzysta z tego rozwiązania. Jeśli tacy pionierzy technologii jak Meta czy Netflix wykorzystują GraphQL’a to tylko kwestia czasu, kiedy inne firmy zaczną z niego korzystać.

Subiektywnie jest wystarczający dowód na to, że GraphQl’a warto w swoim cv mieć. Zwiększa to nasze szanse do dostania się do któregoś z większych graczy w świecie IT. Nawet jeśli nie mamy informacji o tym, czy dana firma produktowa wykorzystuje Graph Query Language, rekruterzy z tej firmy mogą śmielej patrzeć na kandydatów z tą pozycją w umiejętnościach, “na wszelki wypadek”, gdy zostanie podjęta decyzja o implementowaniu.

Na podobnej podstawie warto chwalić się znajomością graphql przy próbie dołączenia do software house’u. Nawet jeśli w danym momencie dom oprogramowania nie posiada projektów z wykorzystaniem tej technologii, zawsze będzie przychylniej patrzeć na developerów z tą umiejętnością, ponieważ ułatwi to w przyszłości przejęcie takiego projektu. 

Wracamy więc do konkluzji postawionej wcześniej. Na pytanie czy warto uczyć się jakiejkolwiek technologii/umiejętności programistycznej, odpowiedź zawsze będzie brzmieć tak, ponieważ nie ma (programistycznej) umiejętności, która nie uatrakcyjni naszego cv.

…Ale czy must have?

Nie. I jeszcze długo pewnie nie będzie. Znaczna część systemów już postawionych operuje na zasadach REST i większość API udostępnianych przez różnego rodzaju dostawców również jest REST’owych. A szkoda, ale może dzięki temu, że więcej osób będzie miała GraphQL’a wpisanego w cv stanie się on popularniejszy i powszechniejszy, co da pole do zaimplementowania tego rozwiązania w większej ilości aplikacji.

I kto wie, może kiedyś będę mógł jednym zapytaniem, zamiast ponad setką pobierać wszystkie potrzebne informacje.

Zdjęcie główne artykułu pochodzi z unsplash.com.

Python Developer w STX Next

Entuzjasta każdego rodzaju technologii odkąd miał w posiadaniu komputer, ale serce skradzione przez Pythona. W czasie wolnym fan Type-Scripta. Gdyby nie programowanie, byłby kucharzem.

Podobne artykuły

[wpdevart_facebook_comment curent_url="https://justjoin.it/blog/graphql-co-to" order_type="social" width="100%" count_of_comments="8" ]