Architektura aplikacji internetowych

Mówiąc luźno, aplikacja internetowa jest programem, który działa na komputerze z serwerem internetowym.

Serwer WWW nie musi tworzyć HTML, CSS, obrazów i skryptów dla swoich klientów. Jeśli jest to zamierzone, nazywamy serwer + klient aplikacją webową. Jeśli serwer produkuje tylko surowe dane (zazwyczaj w tekście lub JSON), wtedy mówimy o serwisie internetowym.

Przykład

Gmail jest aplikacją internetową. Wszystko czego potrzebują użytkownicy to przeglądarka internetowa. Logują się, tworzą i organizują filtry, czytają wiadomości, odpowiadają, przesyłają dalej, wysyłają i usuwają oraz wylogowują się. Wiadomości znajdują się w magazynie danych na serwerze, podobnie jak cały kod do generowania stron. Oczywiście "strony" zawierają sporą ilość skryptów, które przeglądarka wie jak je wykonać, ale należy pamiętać, że te skrypty są przechowywane na serwerze i pobierane na żądanie.

Aplikacje internetowe vs. Aplikacje natywne

Z aplikacjami webowymi nie trzeba pakować oprogramowania do dystrybucji i instalacji na komputerach klienckich. Aktualizacja oprogramowania jest również łatwiejsza, ponieważ nie musisz wysyłać aktualizacji i masz nadzieję, że użytkownicy wiedzą jak ją zainstalować. Wystarczy, że sam dokonasz zmiany na serwerze, a użytkownicy zobaczą nową wersję przy kolejnej wizycie na Twojej stronie (choć niektóre przeglądarki buforowały stare strony trochę zbyt agresywnie).

Dyskusja:

• Klienci kontaktują się z klientami, którzy mogą być klientami internetowymi, lub klientami natywnymi dla iOS lub Androida.
• Klient internetowy jest tradycyjną aplikacją internetową: obsługuje HTML i CSS oraz JavaScript.
• Część serwerowa klienta sieci nie rozmawia bezpośrednio ze składem danych biznesowych; zamiast tego strażnik danych biznesowych jest usługą sieciową. Serwer ten może wystawić na działanie usługi REST API lub GraphQL. Często jest on znany jako "API".
• Sklep z danymi podstawowymi może być relacyjną bazą danych, bazą dokumentów, bazą wykresów, a może zestawem różnych sklepów, w tym indeksów wyszukiwania, a może nawet hurtowni danych. API abstrahuje, jak fizycznie baza danych jest zbudowana.
• API zazwyczaj wspiera dostęp CRUD (tworzenie, pobieranie, aktualizacja, usuwanie) do zasobów biznesowych.
• Niektóre wywołania API mogą powodować wysyłanie powiadomień, takich jak e-maile do klientów.
• Klienci mogą rozmawiać bezpośrednio z assetem (lub sklepem medialnym). Będziesz chciał przechowywać zdjęcia, filmy i duże dokumenty w sklepie z aktywami, a nie w bazie danych Twojej firmy. Klienci zazwyczaj zwracają się do sklepu z danymi podstawowymi o bezpieczny, zbombardowany czasowo adres URL, aby uzyskać dostęp do sklepu z aktywami.
• Przesyłanie dużych zasobów powinno powodować generowanie miniaturek. Miniatury obrazów są następnie zapisywane do drugiego sklepu z aktywami tylko dla miniatur.
• Wiele zasobów będzie wymagało dodatkowego przetwarzania, np. kodowanie wideo, proces przetwarzania obrazu, optyczne rozpoznawanie znaków lub analiza przez oprogramowanie do uczenia maszynowego (np. do wykrywania cech). Wyniki takiego przetwarzania mogą być zapisywane w obszarze holdingu, a inny proces może pobierać dane z tego magazynu i powiększać dane biznesowe o te nowe informacje.
• Wszystko powinno być rejestrowane.
• Administratorzy i zaufani programiści mogą potrzebować, od czasu do czasu, zajrzeć bezpośrednio do sklepu z danymi. Nigdy nie powinni robić tego z własnych maszyn; raczej tunelowaliby się do hosta bastionu w tej samej grupie bezpieczeństwa co magazyn danych.