Szeroka Perspektywa Full-Stack Web Developmentu: Schemat komunikacji

0:00Domyślam się, że masz ogólne pojęcie na temat tego, co dzieje się pomiędzy

0:04klientem a serwerem w momencie wymiany informacji np.

0:08gdy użytkownik wchodzi na stronę i wykonuje jakieś akcje.

0:11Przyjrzyjmy się jednak temu procesowi

0:13nieco bliżej, ponieważ bardzo zależy mi na tym, aby zwrócić Twoją uwagę na kilka

0:17detali, które na ten moment mogą Ci umykać.

0:20Przede wszystkim chciałbym jeszcze zaznaczyć, że będziemy posługiwać się

0:23bardzo prostymi schematami, aby uchwycić tutaj ogólny schemat komunikacji.

0:28Pamiętaj proszę, że każdy z tych etapów

0:30może być bardzo złożony i nawet miejscami się nieco różnić.

0:34Jednocześnie ogólna zasada niemal zawsze

0:36pozostaje taka sama, czyli klient kontaktuje się z serwerem po to, aby

0:40uzyskać jakieś informacje i następnie serwer zwraca te informacje w odpowiednim

0:45formacie do klienta, a ten musi odpowiednio je wyświetlić użytkownikowi.

0:50Zwykle klientem jest tutaj przeglądarka, ale wcale tak być nie musi.

0:53Mianowicie klientem może być też aplikacja desktopowa, bądź chociażby jakieś fizyczne

0:58urządzenie, bądź bardziej oprogramowanie działające na nim.

1:02Jeżeli chodzi o serwer to również tutaj sytuacja może być złożona, ponieważ czasem

1:06może to być serwer dedykowany, czasem może być to wirtualny serwer, a jeszcze innym

1:11razem może być to funkcja działająca w chmurze.

1:14Niezależnie od tego jak wygląda ten schemat i tak ogólna zasada jest taka sama

1:19informacje trafiają z klienta na serwer, gdzie są przetwarzane i w jakiś sposób

1:23przygotowywana jest odpowiedź, która ponownie trafia do klienta i tam jest

1:27odpowiednio interpretowana, a następnie wyświetlana użytkownikowi końcowemu.

1:32I w ten oto sposób odbywa się komunikacja,

1:34której jesteśmy świadkami jako użytkownicy Internetu, a jednocześnie też

1:40przyjdzie nam rozumieć, co tutaj dokładnie dzieje się pod maską.

1:43A dzieje się dość dużo, ponieważ nawet w przypadku bardzo prostej komunikacji, o

1:47której powiedziałem przed chwilą, i tak mamy do czynienia nawet w uproszczeniu z

1:51wieloma krokami, które muszą zostać podjęte.

1:54Zatem zacznijmy od tego, że użytkownik

1:56wpisując pl w swojej przeglądarce oczekuje tego, aby zobaczyć najlepsze dostępne QC.

2:03Zanim to jednak będzie możliwe, w

2:04pierwszej kolejności ten adres musi zostać zamieniony na adres IP.

2:08Coś takiego dzieje się z pomocą rekordów

2:10DNS, które przyjdzie Ci ustawiać w momencie, gdy będziesz konfigurować albo

2:14nowe projekty, albo rozszerzać istniejące o np.

2:18subdomeny. W takiej sytuacji w uproszczeniu mówimy o

2:21połączeniu domeny bądź subdomeny z konkretnym serwerem i to dzieje się

2:25właśnie poprzez dodanie odpowiednich rekordów DNS, które na etapie komunikacji

2:30służą do przetłumaczenia adresu URL na adres IP.

2:34Następnie mamy wspomniany już serwer i tutaj znowu mamy wiele opcji dotyczących

2:39tego, czym konkretnie może być taki serwer.

2:41W większości przypadków są to albo serwery dedykowane tzw.

2:45dedicated server, które jest sprawdza się w przypadku większych aplikacji, ale też

2:49jest odpowiednio droższy lub też wirtualny serwer prywatny, który ja np.

2:53wykorzystuje do wszystkich swoich projektów w ramach usługi digital.

2:57Owszem, w takiej sytuacji fizycznie nie posiadamy dostępu do swojego sprzętu, ale

3:02wszystko jest skonfigurowane w taki sposób, jakbyśmy faktycznie go mieli.

3:06Jest to idealne rozwiązanie, ponieważ mamy

3:08praktycznie pełną kontrolę nad tym, co się dzieje po stronie tego serwera, a

3:12jednocześnie też koszty są odpowiednio niższe.

3:15No i ostatecznie mamy jeszcze serwery współdzielone, w przypadku których cena

3:19jest najniższa, a jednocześnie możliwości zwykle bardzo mocno ograniczone.

3:23W każdym razie to co mogę Ci na tym etapie

3:26polecić to właśnie zainwestowanie nawet kilku dolarów w wirtualny serwer prywatny,

3:30który możesz wykorzystywać na potrzeby nauki bądź jakiś swoich mniejszych

3:34projektów lub też nawet w większości przypadków obsługiwać większe projekty np.

3:39w przypadku Twojego pracodawcę.

3:41Naturalnie tutaj już wchodzimy w obszar

3:43administracji serwerami i z całą pewnością jako full stack.

3:46Nie musisz wiedzieć wszystkiego na ten

3:48temat, ale całkiem dobrym pomysłem jest zdobycie umiejętności, które pozwolą Ci

3:52połączyć się z takim serwerem i wykonać na nim przynajmniej podstawowe operacje.

3:57W moim przypadku po prostu wygląda to tak,

3:59że do samej konfiguracji serwera i jego odpowiedniego ustawienia zwracam się do

4:03jakiejś doświadczonej osoby, która wie co robi w tym temacie, a następnie

4:07przygotowuje mi odpowiednią instrukcję do tego, aby potem móc pracować samodzielnie.

4:13Idąc dalej, w momencie gdy nasze zapytanie trafia do tego serwera, musi zostać

4:17odpowiednio sklasyfikowane i też dostarczone do naszej aplikacji.

4:22I w tym obszarze narzędziami, które wchodzą do gry są tak zwane web serwery.

4:26Najpopularniejsze z nich to Engine i Apache.

4:29Jeżeli chodzi o ich konfigurację, również tutaj można albo polegać na osobie, która

4:34ustawi nam ten serwer, a następnie ewentualnie będziemy modyfikować jego

4:37konfigurację lub też ewentualnie możemy poświęcić chwilę czasu na naukę jej,

4:42która powinna wystarczyć nam do konfiguracji naszych aplikacji.

4:46Do tego tematu będziemy sobie jeszcze wracać i tutaj.

4:49Wracając do głównego wątku jeżeli chodzi o

4:52web serwer, to jego zadaniem jest właśnie klasyfikowanie tego, w które miejsce na

4:56naszym serwerze ma trafić zapytanie pochodzące od użytkownika.

4:59W przypadku Edu Łeba jest to aplikacja stworzona w necie i to właśnie engine

5:04odpowiada za to, aby przekierować do niej zapytanie.

5:07Następnie wewnątrz tej aplikacji również dochodzi między innymi do tzw.

5:11routingu, czyli po prostu podjęcia decyzji o tym, do którego miejsca już wewnątrz

5:16aplikacji ma trafić to konkretne zapytanie.

5:19W większości przypadków zinterpretowania takiego zapytania oraz przygotowanie

5:23odpowiedzi wymaga połączenia z bazą danych w celu pobrania jakiejś informacji i np.

5:29jakiegoś sposobu ich weryfikacji.

5:31Następnie na podstawie tego wszystkiego

5:33aplikacja przygotowuje odpowiedź, która również wraca dokładnie tą samą ścieżką aż

5:38do przeglądarki, gdzie użytkownik z pomocą aplikacji działającej na front endzie

5:42otrzymuje wizualną reprezentację tej informacji.

5:46I teraz upraszczając ten cały proces,

5:48polega on wyłącznie na tym, że użytkownik wpisując jakiś adres w swojej przeglądarce

5:52zostaje połączony z serwerem, na którym działa aplikacja, która interpretuje

5:57zapytanie oraz zwraca odpowiedź użytkownikowi.

6:00Warto jednak tutaj zauważyć, że taka

6:02komunikacja może zostać podzielona na wiele małych fragmentów.

6:05Przykładowo na stronie edu.

6:07PL znajduje się wiele różnych obrazków.

6:09W związku z tym każdy obrazek to tak naprawdę zapytanie do naszego serwera.

6:13Podobnie też jeżeli na tej stronie

6:15znajdują się jakieś dynamiczne elementy, które są pobierane w momencie przeglądania

6:19strony, to również dochodzi tutaj do kolejnych zapytań.

6:23Domyślam się, że masz tego świadomość, jednak trzeba to brać pod uwagę ze względu

6:27na to, że wykonanie każdego z takich zapytań po prostu zajmuje czas.

6:32Z tego powodu z punktu widzenia optymalizacji w niektórych przypadkach

6:35warto połączyć jakieś zapytania w jedno, a w innym przypadku wręcz przeciwnie, np.

6:40w momencie, gdy przejdziemy sobie teraz do katalogu kursów na siebie, to zobaczymy,

6:45że akurat w tym przypadku mamy wyświetlone wszystkie kursy na jednej stronie.

6:49Jednak tak naprawdę kursy są podzielone na kategorie i podkategorie, a to oznacza, że

6:54nie wczytujemy ich wszystkich za jednym razem.

6:57Po prostu w przypadkach, gdy mamy do

6:59czynienia z dużą liczbą danych, znacznie lepszym pomysłem jest podzielenie jej na

7:03kategorie lub też wykorzystanie mechanizmów takich jak tagi.

7:07Do tego, aby uniknąć sytuacji, w której

7:09jakieś zapytanie pobiera zbyt dużą ilość danych, które muszą zostać przetworzone po

7:14stronie klienta i też odpowiednio tam wyświetlone.

7:17W zamian możemy podać tylko kawałek i

7:19tylko w razie potrzeby pobrać kolejne paczki.

7:22Kolejnym bardzo istotnym wątkiem, na który trzeba zwrócić uwagę w przypadku full

7:26stack developmentu jest to, w jaki sposób w ogóle odbywa się komunikacja.

7:31Z punktu widzenia przeglądarki oraz samej aplikacji.

7:34Mianowicie mamy tutaj dwa obrazki

7:36reprezentujące dane przesyłane razem z zapytaniem oraz potem z odpowiedzią.

7:41Zatem jak widzisz, poza faktem, że

7:43wykonujemy tutaj zapytanie na określony adres URL, mamy tutaj do czynienia jeszcze

7:48z metodami HTTP, statusem rekordu, adresami IP czy dodatkowymi informacjami

7:54zapisanych w tak zwanym nagłówku zapytania.

7:56Te wszystkie dane pozwalają komunikować

7:58się albo bezpośrednio z serwerem lub też z naszą aplikacją.

8:02Do tego, aby chociażby była świadoma tego,

8:05w jaki sposób przygotować odpowiedź zwrotną i jednocześnie te wszystkie

8:09informacje, które pozornie stanowią małe detale, takie jak np.

8:12status odpowiedzi, pełnią bardzo ważną rolę z punktu widzenia web developmentu.

8:17Bardzo często zdarza mi się i zakładam, że

8:20Tobie również pracować z API, które nie posługuje się ogólnie przyjętymi

8:24standardami i w rezultacie dochodzi do sytuacji, w których np.

8:27wykonujemy zapytanie do API, które nie zostanie zrealizowane pomyślnie.

8:32Natomiast pomimo tego i tak otrzymujemy

8:34status 200, który sygnalizuje poprawne wykonanie zapytania.

8:38W rezultacie musimy dosłownie domyślać się bądź szukać jakiegoś sposobu na to, aby

8:43odróżnić odpowiedź charakteryzującą pomyślnie wykonane zapytanie od odpowiedzi

8:47na zapytanie, które zostało zrealizowane z błędem.

8:51I tutaj istnieje pewna różnica w momencie, gdy mamy do czynienia z development em.

8:56Różnica polega na tym, że w momencie, gdy

8:58pracujemy wyłącznie na froncie i korzystamy z przygotowanego API, to

9:02zasadniczo nie mamy większej kontroli nad tym, jak to API wygląda w tym przypadku.

9:06Z jednej strony mamy tę kontrolę, ale z drugiej to właśnie na nas ciąży

9:10odpowiedzialność odpowiedniego jego przygotowania.

9:13Tym bardziej, że jeżeli spojrzymy sobie na nagłówki odpowiedzi, to tutaj również

9:17akurat w tym przypadku można teoretycznie stwierdzić, że nie ma tutaj zbyt wielu

9:21istotnych informacji z punktu widzenia developera.

9:24Jednocześnie mamy tutaj elementy, które są

9:27bardzo istotne z punktu widzenia przeglądarki.

9:29Mowa np.

9:30o control, czyli informacji content type, która jest szczególnie ważna w momencie,

9:35gdy pracujemy z API i zwracamy odpowiedzi w różnych formatach, np.

9:40application, styles, Jackson.

9:41Również też odgrywa to istotną rolę w momencie, gdy przesyłamy pliki fizyczne,

9:46gdy przesyłamy pliki takie jak obrazki, bądź też np.

9:49umożliwiamy użytkownikowi wgranie jakiegoś pliku do naszego systemu.

9:54To wszystko odgrywa ogromną rolę zarówno z punktu widzenia frontendu, jak i backendu.

9:59Tak jak powiedziałem,

10:01część z tych elementów będziemy musieli zadbać samodzielnie, a przynajmniej

10:05pamiętać o ich konfiguracji na etapie tworzenia aplikacji.

10:09Dobra wiadomość jest taka, że większość

10:11elementów, które w tym momencie wyświetlają się na ekranie, tak naprawdę

10:15realizowane są automatycznie poprzez frameworki, z którymi przyjdzie nam

10:18pracować, bądź też narzędzia takie jak chociażby Engine EXT.

10:22Ale jednocześnie takie wątki jak metody zapytania, statusy, odpowiedzi, struktura

10:27odpowiedzi, informacja o błędach, typie przekazywanych danych, sposobie kierowania

10:31czy auto rysowania użytkownika oraz uwierzytelnienia połączenia.

10:35To już zostaje w naszych rękach.

10:38Nie przejmuj się, jeżeli na ten moment to wszystko nie jest dla Ciebie jasne.

10:41Ponieważ w kolejnych lekcjach będziemy przyglądać się poszczególnym elementom.

10:45Jednocześnie nie ma też potrzeby, abyśmy

10:47przechodzili przez absolutnie wszystko, ponieważ niektóre elementy są

10:51charakterystyczne typowo dla serwisów takich jak.

10:53Edu.

10:54PL i niekoniecznie za każdym razem musimy zwracać na nie uwagę.

10:58Skupimy się na tym, co jest absolutnie niezbędne do tego, aby zbudować Twój

11:02fundament od zrozumienia sposobu komunikowania się aplikacji i zastosowania

11:07dobrych praktyk, które z całą pewnością będą Ci służyć.

11:10Teraz myślę, że jeszcze ostatnim

11:12elementem, na który warto zwrócić tutaj uwagę jest zakładka Networks w

11:16przeglądarce, z którą z całą pewnością niejednokrotnie przyszło Ci pracować.

11:20Ale też takiej pracy będzie zdecydowanie

11:23więcej w momencie, gdy będziesz pracować jako full stack.

11:25Po prostu z punktu widzenia komunikacji

11:28pomiędzy serwerem a klientem właśnie i zakładka Network oraz Application są

11:33najważniejszymi zaraz po konsoli oraz strukturze DOM elementami.

11:38I tutaj od razu, w momencie, gdy zajrzymy sobie do zakładki Network, widzimy, że na

11:43stronie Web mamy naprawdę dużo zapytań, które składają się tutaj na komunikację.

11:48Rzecz w tym, że uwzględnione są tutaj request nie tylko bezpośrednio do naszego

11:52serwera, ale również zapytania do zewnętrznych usług, takich jak chociażby

11:56Google Analytics czy inne narzędzia analityczne.

11:59Jednocześnie po raz kolejny możemy tutaj eksploatować sobie elementy takie jak np.

12:04Local 103 oraz Session States oraz oczywiście same ciasteczka.

12:08O tym wszystkim będziemy sobie jeszcze rozmawiać, ale naturalnie nie będę Cię

12:11uczył, ponieważ zakładam, że całkiem dobrze je już znasz.

12:15Skupmy się teraz na elemencie dotyczącym

12:17samego ogólnego schematu komunikowania się aplikacji.

12:21Tutaj myślę, że jeszcze dość dobrym pomysłem będzie zajrzenie do Google i

12:25przeszukania kilku grafik zawierających schematy komunikacji różnego rodzaju

12:29aplikacji przy różnych aplikacjach i konfiguracjach.

12:33Przykładowo tutaj mamy jakiś schemat reprezentujący standardową aplikację

12:37webową i w zasadzie jest to dokładnie to, co omówiliśmy przed chwilą.

12:41Jednocześnie w przypadku nieco większych

12:43aplikacji możemy mieć jeszcze do czynienia z tzw.

12:45load balance, którego zasadniczo jest

12:48utrzymanie dużych wolumenów ruchu poprzez rozdzielenie go pomiędzy wieloma

12:52serwerami, które tak jak w tym przypadku mogą współdzielić jedną bazę danych.

12:57Ale oczywiście to też jest tylko schemat,

12:59ponieważ tych baz danych w praktyce również może być więcej.

13:02Przeglądając to wszystko dalej, tutaj mamy

13:05kolejny schemat, który również zasadniczo pokazuje to samo, z tą różnicą, że mamy

13:09tutaj do czynienia z osobą odpowiedzialną za uwierzytelnienie użytkownika i tutaj

13:14też mamy bazę danych, która bezpośrednio z nią współpracuje, a następnie informacje

13:19te wykorzystywane są po stronie web serwera, gdzie możemy decydować, do

13:23których zasobów użytkownik ma dostęp, do których nie.

13:26Następnie też poza samą aplikacją, bądź

13:29też wewnątrz niej możemy mieć do czynienia z osobami odpowiedzialnymi np.

13:33za indeksowanie oraz przeszukiwanie informacji.

13:36Czyli nic innego jak system wyszukiwania.

13:39No i też poza takim systemem możemy mieć serwisy odpowiedzialne za komunikację

13:43mailową, różnego rodzaju powiadomienia, przypomnienia i notyfikacje.

13:48Naturalnie takich usług może być

13:50zdecydowanie więcej i mogą pełnić różne role.

13:53Chodzi mi tutaj o to, aby tylko mieć

13:55świadomość tego, że one istnieją i że mogą pracować ze sobą w różnych konfiguracjach.

14:00To wszystko może zależeć od skali projektu, jakichś problemów, które z

14:04pomocą architektury będziemy chcieli rozwiązać np.

14:07dużego ruchu, bądź też jakiś specyficznych elementów, takich jak np.

14:11celowe odseparowanie części aplikacji, co

14:13może być uzasadnione wyłącznie z punktu widzenia biznesowego.

14:17I teraz jeszcze nie wiem, czy uda mi się tutaj znaleźć jakiś konkretny przykład.

14:21Natomiast w sytuacji, gdy mamy do czynienia z nieco bardziej rozbudowanymi

14:25aplikacjami, do które mogą wchodzić nie tylko load balance,

14:29ale również mechanizmy kierujące, które mogą działać po stronie web serwera i

14:33tutaj mam chociażby na myśli Warning, bądź też na etapie naszej aplikacji.

14:38I tutaj oczko opuszcza nam serwis, bądź też wbudowane mechanizmy kierujące.

14:43Mam nadzieję, że te wszystkie wymienione elementy nie pełnią teraz polegającej na

14:47tym, aby wystraszyć się przed próbą opanowania tego wszystkiego.

14:51Ponieważ prawda jest taka, że nawet jako full stack nie musisz w pełni i bardzo

14:55głęboko posiadać zrozumienia każdego z tych elementów.

14:58Tylko. Wiedzieć, że one istnieją i że w

15:01niektórych sytuacjach przyjdzie Ci z nimi pracować.

15:04Mam nadzieję, że jest to dla ciebie jasne,

15:06więc teraz nie pozostaje mi nic innego, jak zaprosić Cię do kolejnej lekcji.

15:10Dzięki za uwagę i do usłyszenia za chwilę.