Szeroka Perspektywa Full-Stack Web Developmentu: Webhooki

0:00Kolejnym tematem dotyczącym komunikacji aplikacji są wierzchołki.

0:03Często nazywane są odwróconym API ze względu na to, że wykorzystywane są w

0:08kontekście zdarzeń, które dzieją się po stronie aplikacji bądź zewnętrznych usług

0:13i w momencie ich wystąpienia dochodzi do przekazania informacji.

0:17Przykładem może być sklep internetowy,

0:19który w momencie zamówienia oczekuje na zrealizowanie płatności i też informację z

0:24systemu i też informację z systemu płatności, że ta transakcja została

0:28zrealizowana Na podstawie właśnie wierzchołka, który udostępnia taki sklep.

0:33Zostają przesłane niezbędne informacje do tego, aby zidentyfikować daną transakcję i

0:38też przykładowo po pierwsze zarejestrować zrealizowane zamówienie, a po drugie np.

0:43przydzielić klientowi dostęp do produktu.

0:46Jeżeli chodzi o same wierzchołki, to

0:48niezależnie od tego, w którą stronę przesyłają one dane, zwykle mówimy o

0:52unikatowych adresach, które identyfikują konkretną aplikację, bądź też ewentualnie

0:57identyfikują konkretny web, a następnie w zależności od przesłanych

1:01danych na ten web może zostać podjęta różna akcja.

1:05Następnie same wierzchołki mogą zarówno

1:07obsługiwać dane, które trafiają do Twojej aplikacji, czyli to ona wtedy nasłuchuje

1:12na zdarzenia lub też Twoja aplikacja może wysyłać zdarzenia do innych serwisów.

1:17Za chwilę pokażę Ci jak to konkretnie może

1:19wyglądać, natomiast musisz wiedzieć, że zwykle wierzchołki obsługiwane są po

1:24stronie backendu, głównie ze względów bezpieczeństwa,

1:27aczkolwiek oczywiście nic nie stoi na przeszkodzie, aby w sytuacji, gdy to

1:30bezpieczeństwo nie jest aż tak wymagane, móc przesłać dane na wierzchu.

1:34Po stronie frontendu.

1:36Musisz mieć tylko świadomość, że w takiej

1:37sytuacji dość łatwe jest przesłanie niepożądanych danych na taki adres.

1:41Idąc dalej,

1:43koniecznym wymaganiem w przypadku wierzchołków jest logowanie zdarzeń

1:47zarówno tych odbieranych, jak i wysyłanych.

1:49Chodzi o to, że w momencie, gdy mamy do czynienia z usługami, które komunikują się

1:53między sobą, musimy zadbać również o różnego rodzaju błędy.

1:57I tutaj nie mówię tylko o błędach

1:59występujących z przetwarzaniem informacji, ale również o błędach z połączeniem.

2:04Czasem web nie zostanie poprawnie odebrane i w takiej sytuacji konieczne będzie

2:08przynajmniej uzyskanie dostępu do informacji, które miały zostać wysłane.

2:13Następnie jeżeli chodzi o development z wykorzystaniem wierzchołków, to w

2:17przypadku local hosta konieczne jest wystawienie go do sieci.

2:21Przykładowo, jak wiesz zdarza mi się rozwijać system obsługujący płatności.

2:25I właśnie w takiej sytuacji mam do czynienia ze zdarzeniami, które nie tylko

2:29są wysyłane z mojej aplikacji, ale również do nich wracają i wtedy konieczne jest to,

2:34aby zewnętrzna usługa mogła skontaktować się bezpośrednio z moim komputerem.

2:39No i ostatecznie w przypadku tych najbardziej wrażliwych wierzchołków ważne

2:43jest to, aby zastosować mechanizmy obsługujący tzw.

2:47sygnaturę. Jest to dość złożony system zabezpieczeń,

2:50polegający na tym, że praktycznie niemożliwe jest przesłanie i poprawne

2:54obsłużenie danych, które pochodzą z nieautoryzowanego źródła.

2:59I teraz zobaczmy, jak obsługa wierzchołków może wyglądać w praktyce.

3:02Oczywiście na dość prostym przykładzie.

3:05Jak zwykle utworzyłem tutaj prostą

3:07aplikację Messages, która w tym przypadku posiada dwa endpoint.

3:11Jeden umożliwia wykonanie zapytania typu GET i załóżmy, że np.

3:15będzie to obsługa zamówienia, która wymaga

3:18wysłania powiadomienia do zewnętrznej usługi.

3:21Do drugiej endpoint z kolei będzie

3:22reagować na zdarzenia, które trafiają do naszej aplikacji.

3:26W tym przypadku będzie je tutaj logować, a następnie zwracać odpowiedź informującą,

3:31że rzeczywiście doszło do odebrania takiego połączenia.

3:35Nasza aplikacja w tym momencie działa,

3:37więc w momencie, gdy wejdę sobie na adres localhost 3000, no to w tym momencie mam

3:42informację o tym, że zamówienie zostało odebrane.

3:46Ale zwróć uwagę na to, że notyfikacja, która miała zostać przesłana do

3:50zewnętrznej usługi nie została przesłana poprawnie.

3:53Ale jednocześnie tutaj oczywiście tylko mamy console log.

3:56Natomiast nic nie stoi na przeszkodzie,

3:58abyśmy mogli zapisać taką informację w systemie logów, bądź też nawet

4:02bezpośrednio w bazie danych i poinformować użytkownika, kto może być zainteresowany

4:07tą informacją o tym, że notyfikacja nie została odebrana.

4:12Jeżeli teraz ponownie uruchomię tę aplikację, to nasza zewnętrzna usługa

4:16powinna być już dostępna i też mamy tego potwierdzenie.

4:20W związku z tym, że nasz Web Hub został obsługiwanej przez Majkę, to zwróć uwagę,

4:24że mamy tutaj informację, która została przesłana z naszej aplikacji, a tutaj mamy

4:29odpowiedź, która została zwrócona z powrotem i dokładnie wiadomość, która

4:34została przesłana w tym miejscu została wyświetlona również tutaj.

4:38I swoją drogą ja tutaj powtórzyłem to zapytaniem.

4:40Natomiast też warto uwzględnić to, aby pracując z wierzchołkami dostarczać na

4:46przykład jakiś dodatkowy identyfikator bądź cokolwiek, co pozwoli nam stwierdzić,

4:50czy nie zostało wysłane wielokrotnie w sytuacji, gdy nie jest to pożądane, np.

4:55w momencie, gdy informujemy zewnętrzną usługę, że doszło do jakiegoś zamówienia.

5:00Tu raczej nie chcemy przypadkowo wysyłać takich samych powiadomień ponownie.

5:04I teraz jeżeli Cię to interesuje, to tutaj odwołujemy się do tak zwanej warstwy

5:08serwisowej, która odpowiada za przesłanie danych z pomocą Notepad na wskazany adres.

5:14Jedyne co ją interesuje to dane, które chcemy przesłać, a następnie reszta zadań

5:19razem z obsługą błędów dzieją się już w tym miejscu.

5:22No to teraz przyjrzyjmy się jeszcze

5:24drugiemu scenariuszowi, w przypadku którego to make będzie wykorzystywać

5:28akurat moduł HTTP do tego, aby skontaktować się z naszą aplikacją.

5:32I zwróć uwagę, że mam tutaj adres end root, a to oznacza dokładnie tyle, że

5:37aktywowałem sobie tutaj polecenie ng http localhost 3000.

5:42W ten sposób moja aplikacja została udostępniona na świat zewnętrzny, więc po

5:47skopiowaniu tego adresu mogę przekazać go po prostu tutaj.

5:51W rezultacie jeżeli teraz makro wykona

5:54zapytanie na ten adres, no to informacja zostanie przesłana do NG Rock,

5:59a ten w konsekwencji przekaże ją do naszej aplikacji Next.

6:03Efekt końcowy jest dokładnie taki, że informacja z Make trafiła do naszej

6:07aplikacji, a w związku z tym, że wysłaliśmy tutaj obiekt z odpowiedzią,

6:11jesteśmy w stanie go odczytać również tutaj.

6:14Oczywiście miej na uwadze fakt, że w tym momencie korzystamy z platformy Mail,

6:18natomiast tak naprawdę tak samo działa to w przypadku innych usług, które

6:23umożliwiają wymianę danych w jedną lub drugą stronę z pomocą wierzchołków.

6:29I tutaj chciałbym zwrócić Twoją uwagę na fakt, że właśnie w przypadku Maka

6:34wygląda to prawdopodobnie tak, że mamy tutaj do czynienia z oddzielną aplikacją

6:39make, która zajmuje się wyłącznie obsługą wierzchołków.

6:42W związku z tym, że jest to dość duża platforma, jak i też system obsługi takich

6:46zdarzeń jest z całą pewnością bardzo złożony, z dość dużym prawdopodobieństwem

6:51twórcy Maka utworzyli oddzielną aplikację, która prawdopodobnie wystawia tylko jeden

6:56endpoint zawierający unikatowy identyfikator dla każdego z wierzchołków.

7:01Oznacza to, że jako użytkownik jestem w stanie utworzyć sobie nowy wiek, który

7:06zostaje zarejestrowany w bazie i otrzymuje ten unikatowy identyfikator.

7:11W momencie, gdy scenariusz jest aktywny,

7:14również zostaje to odpowiednio oznaczone w bazie i tym samym jeżeli wyślę tutaj

7:18jakieś informacje, zostają one odebrane po stronie Maka.

7:22Jeżeli będziesz rozwijać aplikację, która będzie wymagała od Ciebie utworzenia

7:27podobnego systemu, to również możesz wykorzystać tą koncepcję.

7:31Oczywiście niekoniecznie musisz tutaj od

7:33razu tworzyć oddzielną aplikację, która będzie zajmować się wyłącznie

7:36wierzchołkami, ale oczywiście jeżeli masz ku temu powód, to możesz tak zrobić.

7:41Ważne jest tutaj to, aby wykorzystywać tą

7:43informację o unikatowym identyfikatorze wierzchołka, który zostanie przypisany np.

7:49do konkretnego użytkownika.

7:51My i teraz tak w zasadzie wszystko co do

7:53tej pory powiedziałem obsługuje większość scenariuszy, które dotyczą wierzchołków.

7:57Pamiętaj jeszcze proszę o tym mechanizmie sygnatur oraz aby zawsze brać pod uwagę

8:02to, czy dane, które zostają przesyłane na wierzchołek pochodzą z wiarygodnego źródła

8:07oraz też czy nie są przypadkowo zduplikowane.

8:10Absolutnym wymaganiem, o które naprawdę

8:12warto zadbać, jest też logowanie zdarzeń, które zarówno trafiają na nasz web

8:17oraz informacji zwrotnych, które są z niego wysyłane na zewnątrz.

8:21Nie ma wątpliwości, że przechowywanie

8:23takich informacji może okazać się dla Ciebie pomocne.

8:25Jednocześnie zwracam Twoją uwagę na fakt,

8:28aby w momencie, gdy przykładowo w Twojej aplikacji przesyłane jest hasło bądź inne

8:33wrażliwe dane, to pamiętaj o tym, aby do logów trafiły w formie zabezpieczonej, tak

8:38aby osoba, która uzyska dostęp do tych danych nie była w stanie ich wykorzystać.

8:43A teraz dziękuję Ci za uwagę i zapraszam do kolejnych materiałów.