Progresywne aplikacje internetowe w witrynach wieloźródłowych

Wyzwania i obejścia związane z tworzeniem progresywnych aplikacji internetowych w witrynach z wieloma źródłami.

Demián Renzulli

Opublikowano: 19 sierpnia 2019 r.

W przeszłości używanie architektur z wieloma punktami początkowymi miało pewne zalety. W przypadku progresywnych aplikacji internetowych takie podejście wiąże się z wieloma wyzwaniami. W szczególności zasada tego samego pochodzenia nakłada ograniczenia na udostępnianie takich elementów jak skrypty service worker i pamięci podręczne, uprawnienia oraz na uzyskiwanie samodzielnego działania w przypadku wielu źródeł.

Poznaj dobre i złe zastosowania wielu źródeł oraz wyzwania i obejścia związane z tworzeniem progresywnych aplikacji internetowych w witrynach z wieloma źródłami.

Przykłady prawidłowego i nieprawidłowego użycia wielu punktów początkowych

Istnieje kilka uzasadnionych powodów, dla których witryny stosują architekturę z wieloma źródłami. Dotyczą one głównie udostępniania niezależnego zestawu aplikacji internetowych lub tworzenia środowisk, które są całkowicie od siebie odizolowane. Istnieją też przypadki użycia, których należy unikać.

Dobry

Najpierw zapoznaj się z przydatnymi powodami:

• Lokalizacja/język: używanie domeny krajowej najwyższego poziomu do rozdzielania witryn, które mają być wyświetlane w różnych krajach (np. https://www.google.com.ar), lub używanie subdomen do dzielenia witryn kierowanych na różne lokalizacje (np.: https://newyork.craigslist.org) lub oferować treści w określonym języku (np. https://en.wikipedia.org).

• Niezależne aplikacje internetowe: używanie różnych subdomen do udostępniania treści, których cel znacznie różni się od celu witryny w głównym źródle. Na przykład w witrynie z wiadomościami aplikacja internetowa z krzyżówkami może być celowo udostępniana z domeny https://crosswords.example.com oraz instalowana i używana jako niezależna aplikacja PWA bez konieczności udostępniania zasobów lub funkcji głównej witrynie.

Wady

Jeśli nie robisz żadnej z tych rzeczy, prawdopodobnie użycie architektury z wieloma punktami początkowymi będzie niekorzystne podczas tworzenia progresywnych aplikacji internetowych.

Mimo to wiele witryn nadal ma taką strukturę bez konkretnego powodu lub ze względu na „starsze” rozwiązania. Przykładem jest używanie subdomen do arbitralnego oddzielania części witryny, które powinny być częścią ujednoliconego środowiska.

Na przykład zdecydowanie odradzamy te wzorce:

• Sekcje witryny: rozdzielanie różnych sekcji witryny na subdomeny. W witrynach z wiadomościami często można zobaczyć stronę główną pod adresem https://www.example.com, sekcję sportową pod adresem https://sports.example.com, sekcję polityczną pod adresem https://politics.example.com itd. W przypadku witryny e-commerce możesz użyć na przykład https://category.example.com dla kategorii produktów, https://product.example.com dla stron produktów itd.

• Wzorzec przeglądania: innym odradzanym podejściem jest oddzielanie różnych mniejszych części witryny, np. stron logowania lub procesów zakupu, w subdomenach. Na przykład: https://login.example.com i https://checkout.example.com.

Uwaga: podczas tworzenia witryny od podstaw zdecydowanie zalecamy unikanie dzielenia jej na subdomeny. W przypadku istniejących witryn najlepszym rozwiązaniem jest migracja do jednej domeny.

W przypadkach, gdy migracja do jednej domeny nie jest możliwa, poniżej znajdziesz listę problemów i (jeśli to możliwe) obejść, które można rozważyć podczas tworzenia progresywnych aplikacji internetowych.

Problemy i obejścia dotyczące aplikacji PWA w różnych źródłach

Podczas tworzenia witryny z wieloma źródłami zapewnienie jednolitego działania PWA jest trudne, głównie ze względu na zasadę tego samego źródła, która nakłada szereg ograniczeń. Przyjrzyjmy się im po kolei.

Skrypty service worker

Źródło adresu URL skryptu skryptu service worker musi być takie samo jak źródło strony wywołującej register(). Oznacza to, że na przykład strona pod adresem https://www.example.com nie może wywołać register() z adresem URL skryptu service worker pod adresem https://section.example.com.

Kolejną kwestią jest to, że skrypt service worker może kontrolować tylko strony hostowane w ramach źródła i ścieżki, do których należy. Oznacza to, że jeśli skrypt service worker jest hostowany na stronie https://www.example.com, może kontrolować tylko adresy URL z tego źródła (zgodnie ze ścieżką zdefiniowaną w parametrze zakresu), ale nie będzie kontrolować żadnej strony w innych subdomenach, np. w https://section.example.com.

W takim przypadku jedynym obejściem jest użycie wielu skryptów service worker (po jednym na źródło).

Ostrzeżenie: rejestrowanie i posiadanie wielu aktywnych skryptów service worker zużywa dodatkowe zasoby (pamięć, procesor itp.), dlatego należy dokładnie oszacować, ilu aktywnych skryptów service worker użytkownik będzie prawdopodobnie potrzebować do poruszania się po witrynie.

Buforowanie

Obiekt Cache, indexedDB i localStorage są również ograniczone do jednego źródła. Oznacza to, że nie można uzyskać dostępu do pamięci podręcznych należących do https://www.example.com, na przykład z: https://www.section.example.com.

Oto kilka rzeczy, które możesz zrobić, aby prawidłowo zarządzać pamięcią podręczną w takich sytuacjach:

• Wykorzystaj pamięć podręczną przeglądarki: zawsze zalecamy stosowanie tradycyjnych sprawdzonych metod dotyczących pamięci podręcznej przeglądarki. Ta technika zapewnia dodatkową korzyść polegającą na ponownym użyciu zasobów z pamięci podręcznej w różnych źródłach, czego nie można zrobić z pamięcią podręczną skryptu service worker. Sprawdzone metody korzystania z pamięci podręcznej HTTP z skryptami service worker znajdziesz w tym poście.

• Utrzymuj instalację skryptu service worker na niskim poziomie: jeśli masz kilka skryptów service worker, unikaj obciążania użytkowników dużymi kosztami instalacji za każdym razem, gdy przechodzą do nowego źródła. Innymi słowy: wstępnie przechowuj w pamięci podręcznej tylko te zasoby, które są absolutnie niezbędne.

Gdy skrypt service worker jest aktywny i działa, zasada tego samego pochodzenia ogranicza również żądania współdzielenia wysyłane wewnątrz skryptów service worker. Na szczęście istnieje zalecane obejście tego problemu, które polega na użyciu CORS (jak wyjaśniono tutaj). Nie zalecamy używania trybu no-cors podczas pobierania zasobów w skrypcie service worker.

Uprawnienia

Uprawnienia są też ograniczone do źródeł. Oznacza to, że jeśli użytkownik przyznał określone uprawnienie źródłu https://section.example.com, nie zostanie ono przeniesione na inne źródła, takie jak https://www.example.com.

Nie ma możliwości udostępniania uprawnień między domenami, więc jedynym rozwiązaniem jest poproszenie o uprawnienia w każdej subdomenie, w której wymagana jest dana funkcja (np. lokalizacja). W przypadku takich funkcji jak powiadomienia push w internecie możesz używać pliku cookie, aby śledzić, czy użytkownik zaakceptował uprawnienia w innej subdomenie, i uniknąć ponownego wysyłania prośby.

Instalacja

Aby zainstalować aplikację PWA, każda domena musi mieć własny plik manifestu z wartością start_url, która jest względna względem niej. Oznacza to, że użytkownik, który otrzyma prośbę o instalację w danym originie (np. https://section.example.com), nie będzie mógł zainstalować aplikacji PWA z start_url w innym originie (np. https://www.example.com). Innymi słowy, użytkownicy, którzy otrzymają prośbę o instalację w subdomenie, będą mogli zainstalować aplikacje PWA tylko na podstronach, a nie na głównym adresie URL aplikacji.

Istnieje też problem polegający na tym, że ten sam użytkownik może otrzymać kilka próśb o instalację podczas przeglądania witryny, jeśli każda subdomena spełnia kryteria instalacji i prosi użytkownika o zainstalowanie aplikacji PWA.

Aby rozwiązać ten problem, upewnij się, że prośba jest wyświetlana tylko w głównym źródle. Gdy użytkownik odwiedza subdomenę, która spełnia kryteria instalacji:

1. Nasłuchuj zdarzenia beforeinstallprompt.
2. Zapobiec wyświetlaniu prośby, wywołując event.preventDefault().

Dzięki temu masz pewność, że prośba nie będzie wyświetlana w niezamierzonych częściach witryny, ale nadal będzie widoczna np.w głównym źródle (np. na stronie głównej).

Tryb samodzielny

Podczas nawigacji w samodzielnym oknie przeglądarka będzie zachowywać się inaczej, gdy użytkownik wyjdzie poza zakres ustawiony przez plik manifestu PWA. Zależy to od wersji przeglądarki i jej dostawcy. Na przykład najnowsze wersje Chrome otwierają kartę niestandardową Chrome, gdy użytkownik wychodzi poza zakres w trybie samodzielnym.

W większości przypadków nie ma na to rozwiązania, ale można zastosować obejście w przypadku niewielkich części środowiska hostowanych w subdomenach (np. procesów logowania):

1. Nowy adres URL, https://login.example.com, może otworzyć się w pełnoekranowym elemencie iframe.
2. Po zakończeniu zadania w elemencie iframe (np. procesu logowania) można użyć funkcji postMessage(), aby przekazać wszelkie informacje z elementu iframe z powrotem do strony nadrzędnej.
3. Ostatnim krokiem po odebraniu wiadomości przez stronę główną jest wyrejestrowanie detektorów i usunięcie elementu iframe z DOM.

Uwaga: poprzednia technika może pomóc w ograniczeniu potencjalnej zmiany interfejsu w niewielkiej części witryny, w której użytkownik może wykonać działanie w subdomenie i powrócić do głównego źródła (np. w procesie logowania), ale nie będzie skuteczna w przypadku całych ścieżek, w tym wielu stron hostowanych w subdomenach (np. całych sekcji witryny).

Uwaga: w przypadku zaufanych działań internetowych zalecamy unikanie tego problemu przez weryfikowanie wszystkich źródeł za pomocą Digital Asset Links.

Podsumowanie

Zasada tego samego źródła nakłada wiele ograniczeń na witryny utworzone na podstawie wielu źródeł, które chcą zapewnić spójne działanie PWA. Z tego powodu, aby zapewnić użytkownikom jak najlepsze wrażenia, zdecydowanie odradzamy dzielenie witryn na różne źródła.

W przypadku istniejących witryn, które zostały już utworzone w ten sposób, prawidłowe działanie PWA z wieloma domenami może być trudne, ale znaleźliśmy kilka potencjalnych rozwiązań. Każda z nich ma swoje zalety i wady, więc kieruj się zdrowym rozsądkiem, decydując, które podejście zastosować w swojej witrynie.

Podczas oceny strategii długoterminowej lub zmiany projektu witryny rozważ przejście na jedną domenę, chyba że istnieje ważny powód, aby zachować architekturę z wieloma domenami.

Dziękujemy za recenzje techniczne i sugestie: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle i Andre Bandarra.