Projektowanie aplikacji w taki sposób, aby jak najlepiej wykorzystać technologię, która sprawia, że aplikacje PWA są niezawodne, łatwe do zainstalowania i wydajne, zaczyna się od zrozumienia aplikacji i jej ograniczeń oraz do wybrania odpowiedniej architektury dla obu tych elementów.
SPA i MPA
Obecnie przy tworzeniu stron internetowych wyróżniamy 2 podstawowe wzorce architektury: aplikacje jednostronicowe (SPA) i aplikacje wielostronicowe (MPA).
Aplikacje jednostronicowe to aplikacje, które umożliwiają kontrolowanie po stronie klienta większości lub całego renderowania HTML strony w oparciu o dane pobrane przez aplikację lub do niej dostarczone. Aplikacja zastępuje wbudowaną nawigację przeglądarki, zastępując ją funkcją kierowania i obsługi widoków.
Aplikacje wielostronicowe zwykle zawierają wstępnie renderowany kod HTML wysyłany bezpośrednio do przeglądarki, często wzbogacany o kod JavaScript po stronie klienta po zakończeniu wczytywania kodu HTML przez przeglądarkę. Kolejne wyświetlenia są wykorzystywane przez wbudowane mechanizmy nawigacyjne przeglądarki.
Do tworzenia PWA można używać obu architektur.
Każdy z nich ma swoje wady i zalety. Wybór odpowiedniego rozwiązania do konkretnego zastosowania i kontekstu ma kluczowe znaczenie dla zapewnienia użytkownikom szybkiego i niezawodnego działania.
Aplikacje na jednej stronie
- Głównie niepodzielne aktualizacje na stronie.
- Zależności po stronie klienta wczytywane podczas uruchamiania.
- Kolejne wczytywanie przebiega szybko ze względu na wykorzystanie pamięci podręcznej.
- Wysoki koszt początkowego wczytania.
- Wydajność zależy od sprzętu urządzenia i połączenia sieciowego.
- Wymagana jest dodatkowa złożoność aplikacji.
Aplikacje jednostronicowe dobrze nadają się do architektury, jeśli:
- Interakcja użytkownika koncentruje się głównie na aktualizacjach połączonych danych na tej samej stronie, np. w panelu danych zbieranych w czasie rzeczywistym lub w aplikacji do edycji filmów.
- Twoja aplikacja wykazuje zależności inicjowania tylko po stronie klienta, na przykład w przypadku zewnętrznego dostawcy uwierzytelniania, który ma wyjątkowo wysokie koszty uruchamiania.
- Dane wymagane do wczytania widoku zależą od określonego kontekstu po stronie klienta, na przykład wyświetlania elementów sterujących podłączonym sprzętem.
- Jest na tyle mała i prosta, że jej rozmiar i złożoność nie mają wpływu na wymienione wyżej wady.
SPA mogą nie być dobrym rozwiązaniem, jeśli:
- Wstępne wczytywanie ma kluczowe znaczenie. Aplikacje SPA zwykle muszą wczytywać więcej kodu JavaScript, aby określić, co i jak wyświetlić. Czas analizy i wykonywania tego kodu JavaScript w połączeniu z pobieraniem treści jest dłuższy niż wysyłanie wyrenderowanego kodu HTML.
- Twoja aplikacja działa głównie na urządzeniach o słabej mocy lub średniej mocy. Ponieważ aplikacje SPA opierają się podczas renderowania na języku JavaScript, wrażenia użytkownika w dużej mierze zależą od możliwości konkretnego urządzenia niż w przypadku MPA.
Aplikacje tego typu muszą zastąpić wbudowaną nawigację w przeglądarce swoim routingiem, więc aplikacje te wymagają minimalnego poziomu złożoności sprawnego aktualizowania bieżącego widoku, zarządzania zmianami nawigacji i czyszczenia poprzednich widoków, które w innym przypadku byłyby obsługiwane przez przeglądarkę, co utrudnia ich obsługę i zwiększa obciążenie urządzenia użytkownika.
Aplikacje wielostronicowe
- Aktualizacje zazwyczaj zajmują całą stronę.
- Początkowa szybkość renderowania ma kluczowe znaczenie.
- Skrypty po stronie klienta mogą być ulepszeniami.
- Widoki dodatkowe wymagają innego wywołania serwera.
- Kontekst nie jest przenoszony między widokami.
- Wymaga serwera lub wstępnego renderowania.
Aplikacje wielostronicowe to dobry wybór, jeśli:
- Interakcja użytkownika koncentruje się głównie na wyświetlaniu pojedynczego fragmentu danych oraz opcjonalnych danych zależnych od kontekstu, np. z aplikacji z wiadomościami lub aplikacji e-commerce.
- Początkowa szybkość renderowania ma kluczowe znaczenie, ponieważ przesłanie już wyrenderowanego kodu HTML do przeglądarki trwa krócej niż złożenie go z żądania danych po wczytaniu, przeanalizowaniu i wykonaniu alternatywnej metody opartej na języku JavaScript.
- Po wstępnym wczytaniu danych można uzupełnić interaktywność lub kontekst po stronie klienta, np. nałożyć profil na wyrenderowaną stronę lub dodać dodatkowe komponenty zależne od kontekstu po stronie klienta.
MPA może nie być dobrym rozwiązaniem, jeśli:
- Ponowne pobieranie, analizowanie i ponowne wykonywanie kodu JavaScript lub CSS jest zbyt kosztowne. To połączenie jest ograniczone w aplikacjach PWA z skryptami service worker.
- Kontekst po stronie klienta, np. lokalizacja użytkownika, nie jest płynnie przenoszony między wyświetleniami, a ponowne uzyskanie kontekstu może być kosztowne. Trzeba je zarejestrować i pobrać albo przesłać ponownie między wyświetleniami.
Ponieważ poszczególne widoki danych muszą być renderowane dynamicznie przez serwer lub wstępnie renderowane przed dostępem, co potencjalnie ogranicza hosting lub złożoność danych.
Którą opcję wybrać?
Nawet te wady i zalety obu architektur nadają się do tworzenia PWA. Możesz je nawet łączyć z różnymi częściami aplikacji w zależności od ich potrzeb. Na przykład zadbaj o to, aby informacje o aplikacji były zgodne z architekturą MPA, a proces płatności – architekturą SPA.
Niezależnie od wyboru następnym krokiem jest zrozumienie, jak najlepiej wykorzystać mechanizmy Service Worker, aby zapewnić jak największą wygodę.
Możliwości skryptu service worker
Skrypt service worker ma większe możliwości niż podstawowe kierowanie i dostarczanie odpowiedzi z pamięci podręcznej i odpowiedzi sieciowych. Możemy tworzyć złożone algorytmy, które mogą poprawić komfort korzystania z witryny i jej działanie.
Skrypt service worker obejmuje (SWI)
Kolejnym wzorcem stosowania mechanizmów Service Worker jako integralnej części architektury witryny są mechanizmy Service Worker (SWI).
SWI dzieli poszczególne zasoby, zwykle stronę HTML, na fragmenty w zależności od ich potrzeb w pamięci podręcznej, a następnie łączy je ponownie w skrypcie service worker, aby poprawić spójność, wydajność i niezawodność, a także zmniejszyć rozmiar pamięci podręcznej.
Ten obraz to przykładowa strona internetowa. Zawiera ona 5 różnych sekcji, które są podzielone na następujące części:
- Ogólny układ
- Globalny nagłówek (ciemny górny pasek).
- obszar treści (lewe środkowe linie i obraz);
- Pasek boczny (wysoki średnio ciemny pasek na środku po prawej stronie),
- Stopka (ciemny pasek u dołu).
Ogólny układ
Ogólny układ nie będzie się często zmieniać i nie będzie żadnych zależności. Jest to dobry kandydat do wstępowania w pamięci podręcznej.
Nagłówek i stopka
Globalny nagłówek i stopka zawierają takie elementy jak menu u góry strony i stopka witryny, co stanowi szczególne wyzwanie: jeśli strona ma być zapisana w całości w pamięci podręcznej, wartości te mogą się zmieniać podczas wczytywania strony w zależności od tego, kiedy została zapisana w pamięci podręcznej.
Rozdzielając je i umieszczając w pamięci podręcznej niezależnie od treści, zapewniasz, że użytkownicy zawsze będą mieli dostęp do tej samej wersji bez względu na to, kiedy są przechowywane w pamięci podręcznej. Ponieważ są one rzadko aktualizowane, są też dobrymi kandydatami do stosowania nauczania. Jest jednak pewna zależność: kod CSS i JavaScript witryny.
CSS i JavaScript
W idealnej sytuacji pliki CSS i JavaScript witryny powinny być przechowywane w pamięci podręcznej z nieaktualnym kodem do weryfikacji, aby umożliwić stopniowe aktualizacje bez konieczności aktualizacji skryptu service worker (jak ma to miejsce w przypadku zasobów wstępnie zapisanych w pamięci podręcznej). Muszą one jednak być też przechowywane w minimalnej wersji za każdym razem, gdy skrypt service worker doda nowy globalny nagłówek lub stopkę. Z tego względu po zainstalowaniu skryptu service worker również pamięć podręczna powinna zostać zaktualizowana o najnowszą wersję zasobów.
Obszar treści
Następny jest obszar treści. W zależności od częstotliwości aktualizacji dobrą strategią jest w tym przypadku wybór między siecią lub nieaktualny podczas ponownej weryfikacji. Obrazy należy umieszczać w pamięci podręcznej w pierwszej kolejności, jak zostało to omówione wcześniej.
Pasek boczny
Przy założeniu, że zawartość paska bocznego zawiera dodatkowe treści, takie jak tagi i podobne elementy, nie można pobierać danych z sieci. W tym celu sprawdza się nieaktualna strategia ponownej weryfikacji.
Po zapoznaniu się z tym wszystkim może się wydawać, że taki rodzaj buforowania dla poszczególnych sekcji można zrobić tylko w przypadku aplikacji jednostronicowych. Możesz jednak zastosować w skrypcie service worker wzorce inspirowane mechanizmami zawartych w środowisku brzegowym lub uwzględniających po stronie serwera wraz z kilkoma zaawansowanymi funkcjami skryptu service worker w przypadku każdej z architektur.
Zobacz, jak to działa
Możesz wypróbować elementy, które skrypt service worker uwzględni w następnym ćwiczeniu w programowaniu:
Strumieniowanie odpowiedzi
Poprzednia strona można utworzyć za pomocą modelu powłoki aplikacji w świecie SPA, gdzie powłoka jest zapisywana w pamięci podręcznej i wyświetlana, a treści są wczytywane po stronie klienta. Dzięki wprowadzeniu i szerokiej dostępności interfejsu Streams API w skrypcie service worker można połączyć zarówno powłokę aplikacji, jak i jej zawartość, a potem przesyłać je strumieniowo do przeglądarki. Zapewnia to elastyczność powłoki aplikacji w pamięci podręcznej z prędkością MPA.
Dzieje się tak, ponieważ:
- Strumienie można tworzyć asynchronicznie, co pozwala na przesyłanie różnych fragmentów strumienia z innych źródeł.
- Zgłaszający żądanie strumienia może zacząć pracować nad odpowiedzią, gdy tylko będzie dostępny pierwszy fragment danych, zamiast czekać na zakończenie całego elementu.
- Parsery zoptymalizowane pod kątem strumieniowego przesyłania danych, w tym przeglądarka, mogą stopniowo wyświetlać zawartość strumienia przed jego zakończeniem, co przyspiesza postrzeganą wydajność odpowiedzi.
Dzięki tym 3 właściwościom strumieni danych architektonicznych zbudowanych wokół strumieniowania zwykle widać szybsze działanie niż inne.
Praca z interfejsem Streams API może być trudna, ponieważ jest złożona i ma niski poziom. Na szczęście dostępny jest moduł Workbox, który ułatwia skonfigurowanie odpowiedzi przesyłanych strumieniowo przez mechanizmy Service Worker.
Domeny, źródła i zakres PWA
Procesy internetowe, w tym mechanizmy Service Worker, pamięć masowa, a nawet okna zainstalowanej aplikacji PWA, podlegają jednemu z najważniejszych mechanizmów zabezpieczeń w internecie – zasadom z tego samego źródła. W ramach tego samego źródła uprawnienia są przyznawane, dane można udostępniać, a skrypt service worker może komunikować się z różnymi klientami. Pochodzące z tego samego źródła uprawnienia nie są przyznawane automatycznie, a dane są izolowane i nie są dostępne między różnymi źródłami.
Zasada dotycząca tego samego pochodzenia
Jeśli protokół, port i host są takie same, 2 adresy URL są uznawane za mające dokładne pochodzenie.
Na przykład: https://squoosh.app i https://squoosh.app/v2 mają to samo pochodzenie, ale http://squoosh.app, https://squoosh.com, https://app.squoosh.app i https://squoosh.app:8080 mają inne pochodzenie. Więcej informacji i przykłady znajdziesz w dokumentacji dotyczącej tej samej domeny w MDN.
Zmiana subdomen nie jest jedynym sposobem zmiany hosta. Każdy host składa się z domeny najwyższego poziomu (TLD), domeny dodatkowej (SLD) i 0 lub większej liczby etykiet (nazywanych czasami subdomenami), które są oddzielone kropkami i odczytywane od prawej do lewej w adresie URL. Zmiana dowolnego elementu powoduje zmianę hosta.
W module zarządzania oknami widzimy już, jak wygląda przeglądarka w aplikacji, gdy użytkownik przechodzi do innego źródła niż z zainstalowanej aplikacji PWA.
Przeglądarka w aplikacji pojawi się nawet wtedy, gdy witryny mają tę samą domenę najwyższego poziomu i SLD, ale różnią się etykietami, ponieważ są one uznawane za różne źródła.
Jednym z kluczowych aspektów źródła w kontekście przeglądania internetu jest sposób działania miejsca na dane i uprawnień. Wszystkie treści i aplikacje PWA mają wiele wspólnych cech:
- Limit miejsca na dane i dane (IndexedDB, pliki cookie, miejsce na dane w internecie, pamięć podręczna).
- Rejestracje instancji roboczych.
- Przyznano lub odmówiono uprawnień (takich jak web push, geolokalizacja, czujniki).
- Rejestracje Web push.
Gdy przenosisz się z jednego źródła do innego, wszystkie poprzednie uprawnienia dostępu zostają unieważnione, więc musisz ponownie przyznać uprawnienia, a PWA nie będzie mieć dostępu do wszystkich danych zapisanych w pamięci.