Szeroka Perspektywa Full-Stack Web Developmentu: Komunikacja w praktyce

0:00W tej lekcji podsumujemy sobie

0:01najważniejsze wątki w temacie komunikacji z wykorzystaniem protokołu HTTP.

0:06Przede wszystkim do wykonywania zapytań.

0:08Aktualnie najlepiej jest wykorzystywać PHP oraz inną rzecz.

0:12Warto jednak tutaj podkreślić, że od

0:14wersji 18 noda nie ma potrzeby wykorzystywania zewnętrznych paczek ze

0:19względu na to, że pojawia się już tam natywne wsparcie dla PHP.

0:23Idąc dalej w związku z tym, że przyjdzie

0:24nam pracować zarówno z naszym API oraz też API zewnętrznych usług, warto w zależności

0:30od potrzeb przygotować sobie parser błędów.

0:32Jest to nic innego jak funkcja, która umożliwi Ci łatwe zarządzanie komunikatami

0:37o błędach, tak aby były jak najbardziej przyjazne zarówno dla użytkownika, jaki na

0:41potrzeby logowania różnych zdarzeń w Twojej aplikacji.

0:45Podobnie też możesz stosować różnego rodzaju helper, których celem przede

0:49wszystkim będzie to, aby ułatwić samą komunikację poprzez realizowanie w jednym

0:53miejscu powtarzalnych zadań, takich jak chociażby jakieś transformacje danych,

0:57które przychodzą do Twojej aplikacji lub tych, które są z niej wysyłane.

1:02No i ostatecznie na etat.

1:03Parser Helper warto też wykorzystywać, aby przygotować sobie globalne handler.

1:09Oznacza to mniej więcej tyle, aby zarówno

1:11po stronie frontendu, jak i backendu przygotować sobie centralne miejsce

1:15służące do zarządzania tym, w jaki sposób obsługujemy błędy, wyświetlamy je

1:20użytkownikowi czy chociażby logujemy po stronie serwera.

1:23Zaprojektowanie takiego globalnego

1:25Chandlera nie jest do końca prostym zadaniem, aczkolwiek w wielu przypadkach

1:29frameworki, z których będziemy korzystać mocno będą nam to ułatwiać.

1:33Niebawem będziemy zajmować się tym po stronie backendu.

1:36Aczkolwiek miej na uwadze fakt, że podobne

1:38techniki można również stosować po stronie frontendu i jeżeli już jesteśmy przy

1:43technikach, to dobrze jest zwrócić uwagę jeszcze na filtry oraz tzw.

1:47inter capture.

1:48Jest to nic innego jak specjalne funkcje, które wykonywane są pomiędzy jakimiś

1:52akcjami po to, aby przetransformować dane, bądź też odpowiednio je przefiltrować.

1:57Zaraz zobaczymy jak

1:59możemy zastosować w przypadku frontendu, natomiast szerzej po stronie backendu

2:04będziemy sobie jeszcze więcej mówić przy okazji funkcji typu middleware.

2:08No i ostatecznie jeżeli chodzi o techniki związane zarówno z pracą w sferze API,

2:13zasadami helper global, dilerami czy filtrami sektorami.

2:18Myślę, że warto sięgać po inspiracje dostępne na GitHubie.

2:21Mam tutaj na myśli to co już pokazywałem, czyli podglądanie dokumentacji API oraz

2:27tego w jaki sposób zwracane są informacje o błędach.

2:30I przykładowo jeżeli przejdziemy do API Digital Option to widzimy bardzo

2:34dobrze nawet na przykładzie pierwszego z brzegu Endpoint.

2:37To, że mamy tutaj obsługę metody GET,

2:39która zwraca odpowiedzi w postaci 200 401, 429 czyli jak widzisz mamy tutaj do

2:46czynienia z limitami REST, oczywiście z ewentualnymi błędami serwera.

2:50Co więcej, oprócz tego mamy nie tylko

2:52informacje na temat tego, jak wygląda struktura odpowiedzi, ale również jak

2:56wygląda struktura odpowiedzi w przypadku błędów.

2:59Zauważ, że Digital 8 stosuje nie tylko statusy błędów, ale również zamiast kodów

3:04błędów stosuje identyfikatory, które wprost wskazują na konkretny rodzaj błędu.

3:10Zachowanie takiej spójności na przestrzeni całego API, które w tym przypadku jest

3:14niesamowicie rozbudowane, wymaga właśnie zastosowania technik.

3:18Takie jak chociażby globalne handle, które

3:20właśnie dbają chociażby o to, aby nie było tutaj żadnych literówek.

3:24Zatem proponuję, abyśmy przeszli teraz do

3:26kodu i zobaczyli jak to może wyglądać w praktyce.

3:30Zacznijmy więc od prostego przykładu.

3:32Wyślemy sobie zapytanie na adres URL

3:34i tutaj, aby wykonać zapytanie musimy tylko ustawić odpowiednie nagłówki, czyli

3:39metoda post i nagłówki content type oraz autoryzację.

3:43To jest tracie.

3:43Możemy pobrać sobie te informacje, a następnie wyświetlić w konsoli.

3:47Jeżeli teraz uruchomię sobie serwer,

3:49oczywiście wszystko będzie tutaj w porządku.

3:52Natomiast naturalnie jest to klasyczny przykład Happy path, gdzie wystarczy tak

3:56naprawdę jeden mały problem, aby nasza aplikacja przestała działać.

4:00Poza tym nie tylko obsługa błędów jest

4:02tutaj problemem, ale za każdym razem, gdy będziemy chcieli wykonać kolejne zapytanie

4:06do tego API, ciągle będziemy musieli się powtarzać z nagłówkami oraz kluczem API.

4:12Zdecydowanie lepiej więc byłoby przygotować jedną funkcję, która będzie

4:16odpowiedzialna za kontakt z naszym API i to wewnątrz niej będziemy konfigurować te

4:21podstawowe ustawienia, a cała reszta będzie zmienna.

4:25Aby to zrobić, wykorzystamy sobie teraz jedną z technik, aby to osiągnąć

4:30jest wyciągnięcie sobie referencji do Original Fetch, które wykorzystamy do

4:34tego, aby nadpisać metodę fetch dostępną w przeglądarce.

4:38Szczerze mówiąc, jeżeli chodzi o takie

4:40nadpisywanie domyślnych zachowań przeglądarki, ja raczej jestem temu

4:44przeciwny i wydaje mi się, że dobrym pomysłem byłoby tutaj sięgnięcie po inną

4:48nazwę niż fetch, a sam fetch zostawić w spokoju.

4:51Tak czy inaczej nasza funkcja będzie oczywiście zwracała obietnice i będziemy

4:55mogli przekazać do niej dowolną liczbę argumentów, które będziemy tutaj wyciągać.

5:00Następnie odwołamy się do naszego

5:02oryginalnego kwacha po to, aby wykonać zapytanie na wskazany adres URL i

5:07przekazać tutaj dodatkowe opcje konfiguracji.

5:10W rezultacie to co osiągamy w tym miejscu

5:12to po prostu możliwość modyfikowania zachowania metody fetch dla każdego

5:17zapytania, które będzie realizowane w ramach naszej aplikacji.

5:20W tym przypadku napisaniem, które tutaj stosujemy dotyczy ustawienia nagłówków.

5:25Cała reszta można powiedzieć, że pozostaje taka sama.

5:28No to teraz tak naprawdę jedyne co nas

5:30będzie interesowało to to, aby wykonując zapytanie określić tylko metodę zapytania.

5:36Jeżeli teraz ponownie zajrzymy do naszej aplikacji, to ponownie wszystko powinno

5:40działać i informacje o użytkownikach zostają pobrane pomyślnie.

5:44Oczywiście w produkcyjnej aplikacji pamiętaj proszę o tym, aby klucz API, o

5:48ile nie jest publiczny był przechowywany w zmiennych środowiskowych, a nie

5:52bezpośrednio w dostępnym dla użytkownika kodzie aplikacji.

5:55W każdym razie to, co tutaj zyskaliśmy dotyczy przede wszystkim wygody i

5:59elastyczności oraz braku konieczności powtarzania się w przypadku auto

6:04testowania połączenia i ich podstawowej konfiguracji.

6:07Teraz spróbujemy zastosować sobie filtry,

6:09które umożliwią nam między innymi obsługę błędów.

6:13W tym celu na początek zdefiniujemy sobie

6:15typy opisujące użytkownika oraz naszą odpowiedź.

6:18W przypadku naszego API mamy tutaj do czynienia z danymi bądź też właściwością

6:22message, która pojawia się w przypadku błędów.

6:25No to teraz wystarczy, że wykorzystamy składnie to,

6:29aby wykonać zapytanie na wskazany łapką hook, a następnie odczytać dane i

6:33ewentualnie przechwycić błędy z pomocą w tym przypadku Console loga.

6:37No i teraz możemy wykorzystać tutaj destruktora, a następnie odczytać np.

6:42imię pierwszego użytkownika.

6:43I tutaj jeszcze tylko wykorzystamy sobie type i to teraz jeżeli przejdziemy

6:48ponownie do naszej aplikacji okaże się, że to nasz pierwszy użytkownik.

6:53Za to wygląda na to, że jesteśmy krok dalej.

6:55Ale jeżeli teraz nasze API przestanie

6:57działać, to podobnie razem z nim przestaje działać również nasza aplikacja.

7:01A to oznacza mniej więcej tyle, że nasza obsługa błędów nie do końca działa.

7:06W związku z tym, że nasz błąd dzieje się w

7:08momencie parsowania obiektu wyżej, proponuję, abyśmy wykorzystali tutaj nową

7:12metodę o nazwie Filter Response, która będzie przyjmowała odpowiedź i w

7:17zależności od tego, co w tej odpowiedzi zostanie zwrócone, będzie zwracała albo

7:21nasze dane, albo będzie wyrzucać wyjątek, który zostanie przechwycony w tym bloku.

7:26Zatem przede wszystkim będziemy tutaj potrzebowali generacji innego typu, który

7:29będzie określał to, co zostanie odrzucone w przypadku poprawnej odpowiedzi.

7:34Podobnie też określimy

7:36rodzaj danych, które mogą zostać zwrócone z takiej funkcji.

7:39Zatem teraz mamy do czynienia z funkcją,

7:41do której możemy przekazać typ taki jak np.

7:44tablica użytkowników.

7:45Ona zostanie podstawiona w tym miejscu, a następnie argumentem tej funkcji będzie

7:50odpowiedź, której typ pochodzi bezpośrednio z SHP.

7:53I mamy tutaj dokładnie opisane wszystkie właściwości.

7:56A następnie zwracamy obietnicę, która rozwiązuje się do typu

8:01response type, do którego przekazujemy typ naszych danych.

8:04No i teraz w pierwszej kolejności musimy

8:06sprawdzić, czy nagłówek odpowiedzi z serwera zawiera application gn.

8:11Jeżeli tak, to jesteśmy w stanie te

8:13informacje poprawnie odczytać, ale też musimy sprawdzić, czy samo zapytanie

8:17zostało wykonane poprawnie po stronie serwera.

8:20Jeżeli tak się nie stanie, oznacza to, że

8:22otrzymujemy tutaj błąd, który również zawiera obiekt sam możemy odczytać.

8:27W związku z tym wyrzucamy sobie wyjątek, który zostanie przechwycony w tym miejscu.

8:31W przeciwnym razie mamy do czynienia z sytuacją, w której zapytanie zostało

8:35wykonane poprawnie, a w związku z tym możemy bezpiecznie zwrócić wynik.

8:39No i ostatecznie w sytuacji, gdy

8:41nie zwróci nam poprawnej odpowiedzi, czasami mamy do czynienia z błędem serwera

8:45i również zwracamy wyjątek tutaj w tym przypadku również zostanie tutaj

8:49zalogowany, więc nie ma potrzeby robić tego podwójnie.

8:53Tak czy inaczej teraz możemy wykorzystać tą naszą metodę w taki sposób.

8:57I w rezultacie jeżeli tutaj sobie

8:58podejdziemy to wygląda na to, że nasze typy tutaj poprawnie działają.

9:02A jednocześnie jeżeli po raz kolejny wrócimy do naszej aplikacji, no to okaże

9:07się, że w tym momencie nasz serwer nie działa i mamy oczywiście server error, ale

9:11gdy tylko go aktywuje dane zostaną poprawnie odczytane.

9:15Jednocześnie jeżeli dojdzie np.

9:17do błędu z samym połączeniem i przykładowo

9:20jego autoryzacją, zatem mamy tutaj błędny klucz API.

9:23Zostaniemy o tym również poinformowani poprzez status oraz odpowiednią

9:28informację, którą możemy wyświetlić użytkownikowi.

9:31Zatem w tym wszystkim doszliśmy do momentu, w którym po pierwsze nasze

9:34zapytania obsługiwane są globalnie, w związku z tym nie musimy się powtarzać i

9:38jednocześnie poprzez interpreter mamy kontrolę nad tym, w jaki sposób te

9:42zapytania są wysyłane, a jednocześnie dzięki Filipowi mamy też kontrolę nad tym,

9:47co dzieje się z samym zapytaniem i w rezultacie wszędzie tam, gdzie dojdzie do

9:52błędu związanego z samym pobieraniem informacji z API, jesteśmy w stanie

9:56odpowiednio zareagować i ponownie też nie musimy się.

10:00Do tego, aby obsługiwać te same scenariusze wielokrotnie.

10:04Na samym końcu zostały nam jeszcze LP, których aktualnie nie będę już pokazywał.

10:08Natomiast musisz wiedzieć, że LPT możesz wykorzystać np.

10:11po to, żeby w momencie gdy zapytanie

10:13zostanie zrealizowane poprawnie obsłużyć chociażby sytuacje dotyczące chociażby

10:18notyfikacji użytkownika o tym, że zostały pobrane poprawnie lub też ewentualnie

10:23możesz wykorzystać w tym miejscu AVR do tego aby poprawnie odczytać błędy,

10:28które zapis z różnych powodów mogą przychodzić w formacie, który nie nadaje

10:32się do tego, aby wyświetlić go użytkownikowi.

10:35Ostatecznie mam nadzieję, że koncepcja praktycznej pracy z API oraz projektowania

10:39tych globalnych funkcji obsługujących podobne scenariusze jest dla Ciebie jasna.

10:44I jednocześnie pamiętaj proszę o tym, że podobne strategie wykorzystujemy po

10:48stronie backendu, natomiast tam mówimy bardziej o funkcjach typu middleware, o

10:52których jeszcze niejednokrotnie będziemy mówić teraz.

10:55Dzięki za uwagę i do usłyszenia niebawem.