Szeroka Perspektywa Full-Stack Web Developmentu: Wprowadzenie do GraphQL

0:00Gra w Call to tzw.

0:01Query language, stanowiące alternatywę dla REST API.

0:04Sprawdza się szczególnie w przypadku, gdy

0:06mamy do czynienia z aplikacjami, które działają na wielu platformach lub też

0:10chociażby ich skalę wymaga dużej elastyczności, którą zapewnia gra SQL.

0:14W przeciwieństwie do REST API,

0:16jednocześnie w małych i średnich aplikacjach REST API sprawdzi się

0:20zdecydowanie lepiej lub też w kilku innych przypadkach powiemy sobie za chwilę.

0:25Zacznijmy od tego, że najważniejszą różnicą pomiędzy graniem w Call a REST API

0:30jest fakt, że REST API umożliwia nam dostęp do danych poprzez udostępnienie end

0:35pointów, na które możemy kierować zapytania, a w przypadku Graph Call mamy

0:39po prostu jeden endpoint, na który kierujemy wszystkie zapytania, wliczając w

0:43to zarówno pobieranie danych, jak i modyfikowanie czy usuwanie.

0:47Coś takiego na tym etapie powinno podsuwać

0:49Ci już szereg korzyści, które z tego wynikają.

0:52Mianowicie, w momencie, gdy zaprojektujemy

0:54REST API, musimy przede wszystkim przewidzieć dość dokładnie jakie dane będą

0:58dostępne dla klienta oraz w jaki sposób będzie wchodzić z nimi w interakcje.

1:03Co więcej, mamy tutaj pewne ograniczenia,

1:05o ile oczywiście ich w jakiś sposób nie adresujemy.

1:08Przykładowo wyobraź sobie sytuację, w której chcesz pobrać użytkowników, ale tak

1:12naprawdę interesują Cię tylko ich adresy email.

1:15Teoretycznie moglibyśmy podać tutaj

1:17dodatkowy parametr i respektować go w momencie pobierania informacji na temat

1:21użytkowników, aby do klienta zwrócić tylko te wybrane pola.

1:25Ale co w sytuacji, gdy razem z

1:27użytkownikami będziemy chcieli zwrócić artykuły?

1:30Sytuacja na tym etapie już znacznie się komplikuje.

1:33Jednocześnie w przypadku gra w call dalej

1:35mamy do czynienia z jednym endpoint, który odpowiada za praktycznie wszystko.

1:39Oczywiście to nie jest tak, że działa tutaj jakaś absolutna magia, która

1:43sprawia, że gra w call jest w stanie domyślić się, co chcemy dokładnie pobrać,

1:47ale po prostu ta elastyczność jest odpowiednio większa.

1:50Poza tym istnieje jeszcze szereg różnych

1:53korzyści zarówno REST API, jak i gra SQL, które należy brać pod uwagę w momencie,

1:58gdy zdecydujesz się na jedno bądź drugie rozwiązanie.

2:01Z tego powodu tak dużo uwagi poświęcamy właśnie REST API, a nie gra SQL.

2:05Ze względu na to, że przykładowo ja w moich aplikacjach tylko w pojedynczych

2:09przypadkach sięgam po SQL, ponieważ po prostu nie widzę takiej potrzeby.

2:14Nie zmienia to jednak faktu, że gra SQL obecnie jest już na tyle poważnym graczem,

2:18że na pewno trzeba brać go pod uwagę i wiedzieć w jaki sposób można z niego

2:22skorzystać, przynajmniej od strony użytkownika.

2:25Oczywiście tutaj też wchodzi cały temat

2:27projektowania serwera gra SQL, ale to już znacząco wykracza poza zakres tego

2:32materiału, więc tylko przyjrzymy się jak to może wyglądać.

2:36Na początek być może zastanawia Cię jak to

2:38w ogóle jest możliwe, że jeden endpoint obsługuje praktycznie każdy rodzaj zapytań

2:43i dodatkowo zapewnia nam tak wysoką elastyczność?

2:46Mianowicie w przypadku gdy SQL

2:48zapytanie na wybrany endpoint wygląda w następujący sposób.

2:52Jak widać nie mamy tutaj rozróżnienia

2:54pomiędzy metodami GET oraz POST czy PUT, ale zapisujemy coś w rodzaju obiektu

2:59Jackson, który opisuje strukturę informacji, którą chcemy uzyskać.

3:04Nietrudno się domyślić, że chodzi nam o pobranie informacji na temat użytkowników,

3:08a konkretnie ich imion, emaili, oceny oraz artykułów.

3:13W odpowiedzi na tak zadane zapytanie

3:14otrzymujemy obiekt Jackson o następującej strukturze.

3:18Od razu tutaj widać, że ta struktura

3:20odpowiada dokładnie temu, co zapisaliśmy w zapytaniu.

3:23Zatem mamy tutaj poszczególne pola oraz artykuły.

3:26Tak naprawdę jeszcze to w przypadku artykułów powinniśmy tutaj zapisać

3:30dodatkowe pola, które chcemy na ich temat pobrać.

3:33Zatem załóżmy, że interesuje nas tytuł.

3:35W związku z tym zapytanie będzie wyglądało w taki sposób.

3:38W tym akurat przypadku do tego użytkownika

3:40nie są przypisane żadne artykuły, natomiast gdyby były, to mielibyśmy tutaj

3:45do czynienia z obiektami zawierającymi w tym przypadku jedną właściwość.

3:50Co więcej, nawet w sytuacji, gdybyśmy mieli w tym przypadku do czynienia z

3:53artykułami, pod którymi byłyby komentarze, to aby je pobrać jedyne co musielibyśmy

3:58zrobić, to po stronie frontendu tak naprawdę musielibyśmy dopisać dodatkową

4:03właściwość Comment, gdzie również uwzględnili byśmy np.

4:06ich zawartość czy informacje o autorze.

4:08I właśnie na tym polega cała elastyczność

4:11call, a jednocześnie myślę, że też dość widoczne stają się dla Ciebie zarówno

4:16zalety takiego podejścia, jak i różnego rodzaju wady.

4:19Przykładowo mam tutaj na myśli chociażby

4:21wykorzystanie pamięci podręcznej, którą oferują przeglądarki i z której w

4:25przypadku REST API możemy korzystać praktycznie domyślnie, a w przypadku grafu

4:30Old system pamięci podręcznej musimy konfigurować samodzielnie.

4:33Podobnie też wszystkie odpowiedzi gra SQL zwracają status 200.

4:38W przeciwieństwie do REST API, gdzie

4:39możemy rozróżniać właśnie na podstawie statusów, to, czy na przykład jakaś

4:43operacja została wykonana pomyślnie, czy też nie.

4:46To wszystko prowadzi nas do jednego

4:48wniosku, który całkiem dobrze został podsumowany w tym zdaniu.

4:51Mianowicie w momencie, gdy mamy do czynienia z aplikacją mobilną, bądź też

4:55bardziej wielo platformowa, to najprawdopodobniej lepszym wyborem będzie.

5:00Nie gra w call. W przypadku, gdy potrzebujemy bardzo

5:02ściśle określonego API, takiego na którym będziemy mieć jasną

5:07kontrolę, zdecydowanie lepszym rozwiązaniem będzie REST.

5:10Z mojego doświadczenia wynika to, co

5:12powiedziałem wcześniej, że w większości przypadków w momencie, gdy projektuję małe

5:16i średnie aplikacje, REST API jest w zupełności wystarczające.

5:20Jednak w momencie, gdy przyjdzie mi rozwijać jakiś większy system, bądź też

5:24właśnie wielo platformowe, to myślę, że gra SQL będzie tutaj lepszym wyborem.

5:29Jeżeli sam temat Cię interesuje to odsyłam Cię do artykułów, które wyjaśniają w

5:34bardziej szczegółowy sposób różnice pomiędzy rest API agrafki el oraz

5:39pokazują, które rozwiązanie sprawdzi się w tym przypadku.

5:42Szczerze mówiąc jednak bardzo często można spotkać sytuację, w której autor jest

5:46uprzedzony do konkretnego rozwiązania i na siłę próbuje znaleźć argumenty

5:50przekonujące nas do jednego bądź drugiego rozwiązania.

5:54Wydaje mi się, że dobrze jest wyrobić

5:56sobie własne zdanie i jednocześnie brać pod uwagę elementy takie jak np.

6:00to, czy np. aplikacja, którą budujesz faktycznie

6:03skorzysta na zaletach, czy być może wręcz przeciwnie.

6:07Myślę, że na ten moment wiesz o co mi tutaj chodzi.

6:10Natomiast raz jeszcze podkreślę tutaj, że

6:12w naszym przypadku będziemy opierać się raczej o rest API.

6:16Nie zmienia to jednak faktu, że gra wgl powinien być na Twoim radarze i w momencie

6:20gdy nadejdzie na to odpowiednia chwila, warto, aby brak doświadczenia w jego

6:24wykorzystaniu nie stanął na przeszkodzie, aby skorzystać z jego zalet.

6:28Tutaj jeszcze zanim przejdziemy dalej,

6:30chciałbym podkreślić, że tak jak w tym miejscu mieliśmy do czynienia z zapytaniem

6:34popierającym informację, tak jednocześnie gra SQL oferuje tzw.

6:37mutacje, które umożliwiają nam wykonywanie akcji takich jak np.

6:41aktualizowanie bądź usuwanie zasobu.

6:44To wszystko nadal realizowane jest w tej dość elastycznej strukturze, która pozwala

6:49nam elastycznie definiować to, które pola aktualizujemy i jakie informacje np.

6:53chcemy pobrać w momencie wykonania tego działania.

6:56Czyli tutaj aktualizujemy użytkownika, a konkretnie jego imię i w odpowiedzi

7:01otrzymujemy jego identyfikator oraz zaktualizowane imię.

7:05Jednocześnie już tutaj zaczyna być bardzo widoczne to, że te wszystkie akcje nie

7:10dzieją się automagicznie i ktoś musi zadbać o to, aby gracz wiedział w jaki

7:14sposób interpretować te wszystkie zapytania i co z nimi robić.

7:18Nie będę Cię tutaj oszukiwał, ponieważ jako full stack ta rola przypadnie Tobie.

7:22O ile oczywiście nie korzystasz z

7:24zewnętrznego serwera, do którego podłączasz się poprzez właśnie gra w call.

7:29Zanim jednak przyjrzymy się temu nieco bliżej.

7:31Ja wykonałem już trochę pracy i

7:33przygotowałem bardzo prosty serwis, który udostępnia nam charakterystyczne dla

7:37grafiku El Playground, z pomocą którego możemy wykonywać zapytania takie jak np.

7:42pobieranie informacji na temat użytkowników i mamy tutaj dokładne

7:45odpowiednik tego, co zobaczyliśmy na poprzednich slajdach.

7:49Mianowicie zwróć uwagę, że definiuję tutaj zapytanie.

7:52Dodatkowo nadaje mu tutaj nazwę, która akurat w tym przypadku jest dowolna, a

7:56następnie określa to jakie informacje o jakiej strukturze chcę tutaj pobrać.

8:00Jednak w tym przypadku zwróć uwagę, że zapytaliśmy tutaj o właściwość Active, a

8:05pomimo tego nie otrzymaliśmy jej w odpowiedzi.

8:07Wynika to z faktu, że w tym konkretnym

8:09przypadku ten użytkownik nie posiada tej właściwości.

8:13Jednocześnie jeżeli pobierzemy sobie

8:15informacje na temat użytkownika o identyfikatorze 2,

8:18to w tym przypadku nie jest zaskoczeniem, że otrzymamy odpowiedź w postaci nulla ze

8:22względu na to, że taki użytkownik nie istnieje, ale oczywiście możemy go sobie

8:27utworzyć wykorzystując trzecie zapytanie, które jest mutacją tworzącą użytkownika.

8:32Dzięki temu użytkownik o identyfikatorze 2 już istnieje, więc możemy wykonać

8:37zapytanie, które pobierze informacje na jego temat.

8:40I w rezultacie otrzymujemy dokładnie taką odpowiedź.

8:43Naturalnie, jeżeli chciałbym tutaj coś

8:45zmodyfikować i na przykład pobrać wyłącznie adres email, to oczywiście

8:49zostanie tutaj zastosowane i odpowiedź będzie posiadała taką, a nie inną formę.

8:53Poza tym jeżeli chodzi o sam plik, myślę, że warto rzucić okiem jeszcze na

8:58dokumentację, która swoją drogą generuje się tutaj automatycznie na podstawie tzw.

9:02schematu grafu L, który oczywiście musimy sami przygotować.

9:06Jest to jeden z pierwszych elementów,

9:08które mówi o tym, że w przypadku gdy wgl nie wszystko dzieje się automatycznie.

9:13Nie zmienia to jednak faktu, że

9:15informacje, które mamy tutaj są bardzo użyteczne.

9:18Możemy w ten sposób podglądać, które

9:20właściwości są przykładowo wymagane, a które opcjonalne.

9:23Mamy też dostęp do wszystkich rodzajów, metod i mutacji, które możemy zastosować.

9:28Oznacza to mniej więcej tyle, że wystarczy

9:30spojrzeć na to, co mamy dostępne, aby w prosty sposób przygotować np.

9:35mutacje usuwające użytkownika o wskazanym identyfikatorze.

9:39W naszym przypadku wystarczy podać tutaj dane użytkownika, a konkretnie jego

9:43identyfikator, który pozwoli nam go odnaleźć, a następnie określić, jakie

9:48informacje chcemy otrzymać w odpowiedzi zwrotnej.

9:51Zatem teraz po usunięciu tego użytkownika otrzymujemy informację zwrotną, że

9:55operacja została wykonana poprawnie, a do tego użytkownika to.

10:01I właśnie tak wygląda wchodzenie w interakcję z serwerem SQL oraz wysyłaniem

10:05do niego zapytań oraz mutacji, które modyfikują bądź usuwają dane.

10:10Naturalnie w zależności od tego, czy

10:12będziesz projektować własny serwer SQL, czy też po prostu wykorzystywać go po

10:16stronie swojej aplikacji po stronie frontendu zależy już od Twoich potrzeb.

10:21Dobra wiadomość jest taka, że w

10:22ekosystemie JavaScriptu praktycznie wszystkie dostępne, a przynajmniej te

10:26najpopularniejsze frameworki umożliwiają bezproblemową integrację z gra wgl.

10:31Myślę, że taką najważniejszą informacją,

10:33którą musisz zapamiętać z tej lekcji jest fakt, że gra SQL w przeciwieństwie do REST

10:38API oferuje dostęp do danych w sposób elastyczny za pośrednictwem jednego end

10:42pointa, gdzie po prostu określamy jaki rodzaj zapytania chcemy wykonać.

10:47A serwer SQL przygotowany jest w taki

10:49sposób, aby móc przygotować stosowną dla nas odpowiedź.

10:53Jeżeli chodzi o szybkie wprowadzenie do gra SQL, to by było na tyle.

10:57W związku z tym nie pozostaje mi nic

10:58innego jak zaprosić Cię do kolejnej lekcji.

11:01Dzięki za uwagę i do usłyszenia za chwilę.