Architektura aplikacji webowych – szczegóły

Nasz świat jest pewnym rodzajem systemu. Musimy to zrozumieć, aby móc nim zarządzać. Wyobraź sobie, że podobnie jest z budowaniem aplikacji internetowej - powinieneś znać kontekst niezbędny do stworzenia systemu. Temat, który dziś poruszamy zajmuje honorowe miejsce w tworzeniu oprogramowania – to oczywiście architektura aplikacji internetowych. Artykuł ma na celu pomóc osobom nietechnicznym lepiej zrozumieć techniczną stronę firmy i poprawić komunikację z programistami. 

Architektura aplikacji internetowych w szczegółach

Większość osób choćby luźno związanych z branżą IT, ma podstawowe wyobrażenie o tym, jak działa architektura aplikacji internetowych. Aplikacja front end wysyła żądanie do aplikacji back-endu, która z kolei wysyła je do bazy danych i wykonuje logikę biznesową, po czym wraca z odpowiedzią do front end.

Strona zaplecza

Po stronie serwera (back-end) mamy aplikację lub zestaw aplikacji podłączonych do Internetu lub chmury. Dwa komponenty, które definiują zaplecze to serwery www i bazy danych.

Serwer www jest łatwy do zrozumienia, ale też skomplikowania. Proces serwera www to wszystko, co odpowiada na żądanie HTTP i zwraca do niego plik. Za pomocą serwera www programista może utworzyć statyczną stronę, która nie robi nic poza prezentowaniem informacji.

Druga część zaplecza to baza danych. Każdy półinteligentny serwer www wykorzystuje bazę danych, która coś utrzymuje. Baza danych niekoniecznie jest związana z technologiami internetowymi. Na przykład szpitale przechowują dane lekarzy i pacjentów w systemie plików. To jest baza danych offline. Nie każda baza danych potrzebuje serwera www, ale 99% projektów z serwerem www wymaga bazy danych.

W większości przypadków serwer i baza danych znajdują się na różnych komputerach, ale mają własne połączenie, co zapewnia wyższą wydajność i optymalne wykorzystanie przestrzeni.

Back-end to system połączonych komputerów, które komunikują się ze sobą. W prawdziwych aplikacjach www zaplecze nie ogranicza się do serwera i bazy danych. Istnieje ponad 30 procesów działających na zapleczu aplikacji. Jeśli naciśniesz przycisk „Kup” na Etsy, zlecenie trafi nie tylko do serwera www i bazy danych, ale też do 50 komputerów przetwarzających Twoje zapytanie. Trafi ono do systemu płatności, zapasów, bezpieczeństwa, powiadomień, aby poinformować dostawcę, żeby zaczął przygotowywać zamówienie.

Dodatkowe procesy

Proces w tle ma miejsce, gdy potrzebujesz więcej czasu na przetworzenie żądania. Strona internetowa jest szybka, ale czasem jej załadowanie zajmuje więcej czasu. Przetwarzanie w tle eliminuje czas oczekiwania użytkownika. Radzi sobie z rzeczami, które fizycznie zajmują więcej czasu, np. zgniatanie liczb, przetwarzanie ogromnej ilości danych.

Drugim procesem jest buforowanie. W najbardziej podstawowym przypadku użycia otrzymujesz żądanie z serwera www i trafia ono do bazy danych, która odpowiada. Jednak trafienie do bazy danych może być kosztownym zadaniem, zwłaszcza gdy to samo żądanie zostanie wysłane 100 razy. Dlatego możesz buforować odpowiedź, aby szybciej dać znać klientowi. Pamiętaj o podstawowej idei pamięci podręcznej - szybszym i łatwiejszym dostępie do pytań, wątpliwości i sytuacji które często się zdarzają.

Strona front-end

Zazwyczaj front-end lub strona klienta jest łatwiejsza do konceptualizacji niż back-end. Front-end to dowolny rodzaj kodu, który działa po stronie klienta. Na przykład klient otwiera przeglądarkę Chrome używaną do oglądania wideo.

Główną przesłanką Internetu jest relacja klient-serwer, w której klienci wysyłają żądania do serwera. Zilustrujmy architekturę aplikacji internetowych przy użyciu zwykłych działań offline. Wyobraź sobie, że idziesz do restauracji i zamawiasz stek. Jesteś klientem, a restauracja to serwer. Zamawiasz stek, a restauracja odpowiada posiłkiem. Back-end to restauracja, a front-end to klient.

Zapamiętaj, że front-end i back-end zawsze się łączą. Gdy poprosisz programistę o zmianę, zmiana zostanie wykonana po obu stronach.

Połączenie między zapleczem a interfejsem

Wróćmy do podstawowego modelu: aplikacja front-end jest czymś, z czym współpracujemy i co wysyła żądania do procesów back-end.

Starszym sposobem działania aplikacji internetowych byłby taki proces, że back-end renderowałby cały HTML i zwracał go z powrotem do frontonu, który wyświetla dane. Cały HTML renderowany na zapleczu jest zwracany w odpowiedzi. Przeglądarka musi tylko ją wyświetlić.

Teraz wiele aplikacji korzysta z nowszego modelu, w którym back-end nie zwraca HTML, ale dane. Front-end jest odpowiedzialny za generowanie wszystkich tagów HTML. Za to aplikacja internetowa miesza oba modele, w których zaplecze może odpowiadać 50% strony w HTML, a front end renderuje resztę.

Wniosek

Jako non-tech nie powinieneś jednak myśleć o całej technologii, z którą pracujesz, jak o magicznej czarnej skrzynce. Najlepszą rzeczą jaką możesz zrobić, aby wzmocnić komunikację z programistami, jest zrozumienie, jakie obowiązki spoczywają na różnych częściach systemu technicznego.

► Jeśli masz dodatkowe pytania dotyczące architektury aplikacji internetowych chętnie na nie odpowiemy. Skontaktuj się z nami i uzyskaj bezpłatną konsultację.