GraphQL to ciekawostka w cv czy must have?

geek.justjoin.it 2 lat temu

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, iż powinniśmy odpytać /products/:id.

Logicznie zbudowany schemat, za pomocą którego 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 wszystkich 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 iż 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 wszystkich 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 wszystkich 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, iż 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.

type Query {
orders{ name shipping_address
order_items{
name
}
}
}

Takim skonstruowanym zapytaniem, dostaniemy w odpowiedzi listę zamówień oraz dla wszystkich zamówienia pola name, shipping_address oraz liste order_items z polem name dla wszystkich przedmiotu. choćby jeżeli 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 iż 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, za pomocą którego każdy będzie w stanie załapać zasady od razu!

Idź do oryginalnego materiału