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 korzystanie z architektur wielopochodzeniowych miało pewne zalety. W przypadku progresywnych aplikacji internetowych takie podejście wiąże się z wieloma wyzwaniami. W szczególności zasada takiego samego pochodzenia nakłada ograniczenia na udostępnianie takich elementów jak service worker i pamięć podręczna, uprawnienia oraz na uzyskiwanie niezależnego działania w wielu źródłach.

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

Dobre i złe przykłady użycia wielu domen

Istnieje kilka uzasadnionych powodów, dla których witryny stosują architekturę wielopochodzeniową. Najczęściej jest to związane z udostępnianiem niezależnego zestawu aplikacji internetowych lub tworzeniem środowisk, które są od siebie całkowicie odizolowane. Istnieją też zastosowania, których należy unikać.

Dobry

Najpierw przyjrzyjmy się przydatnym powodom:

• Lokalizacja / język: używanie domeny najwyższego poziomu z kodem kraju do oddzielania 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 przeznaczenie znacznie różni się od 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 i instalowana oraz używana jako niezależna aplikacja PWA bez konieczności udostępniania zasobów ani funkcji głównej witrynie.

Złe

Jeśli nie wykonujesz żadnej z tych czynności, prawdopodobnie korzystanie z architektury wielu źródeł będzie niekorzystne podczas tworzenia progresywnych aplikacji internetowych.

Mimo to wiele witryn nadal jest tak skonstruowanych bez konkretnego powodu lub z powodów „historycznych”. Przykładem jest używanie subdomen do arbitralnego oddzielania części witryny, które powinny być częścią ujednoliconego środowiska.

Na przykład poniższe wzorce są wysoce odradzane:

• Sekcje witryny: oddzielanie różnych sekcji witryny w subdomenach. W przypadku witryn z wiadomościami strona główna często znajduje się pod adresem https://www.example.com, sekcja sportowa pod adresem https://sports.example.com, sekcja polityczna pod adresem https://politics.example.com itd. W przypadku witryny e-commerce możesz używać np. https://category.example.com dla kategorii produktów, https://product.example.com dla stron produktów itp.

• Przepływ użytkownika: inne podejście, które jest odradzane, to oddzielanie różnych mniejszych części witryny, np. stron logowania lub ścieżek zakupu w subdomenach. Na przykład używając https://login.example.com i https://checkout.example.com.

W przypadku, gdy migracja do jednej domeny nie jest możliwa, poniżej znajdziesz listę wyzwań i (w miarę możliwości) obejść, które można wziąć pod uwagę podczas tworzenia progresywnych aplikacji internetowych.

Problemy i rozwiązania dotyczące PWA w różnych źródłach

Tworzenie witryny w wielu źródłach, która zapewnia jednolite działanie PWA, jest trudne, głównie ze względu na zasadę tego samego pochodzenia, która nakłada szereg ograniczeń. Przyjrzyjmy się im po kolei.

Skrypty service worker

Pochodzenie adresu URL skryptu service worker musi być takie samo jak pochodzenie strony wywołującej funkcję register(). Oznacza to, że na przykład strona pod adresem https://www.example.com nie może wywoływać funkcji register() z adresem URL service worker pod adresem https://section.example.com.

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

W takim przypadku jedynym rozwiązaniem jest użycie wielu procesów service worker (po jednym na źródło).

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, np. z https://www.section.example.com.

Oto kilka sposobów prawidłowego zarządzania pamięcią podręczną w takich sytuacjach:

• Korzystaj z pamięci podręcznej przeglądarki: zawsze zalecamy stosowanie tradycyjnych sprawdzonych metod dotyczących pamięci podręcznej przeglądarki. Ta technika ma dodatkową zaletę, jaką jest ponowne wykorzystywanie zasobów z pamięci podręcznej w różnych źródłach, co nie jest możliwe w przypadku pamięci podręcznej modułu service worker. Sprawdzone metody korzystania z pamięci podręcznej HTTP w przypadku service workerów znajdziesz w tym artykule.

• Zadbaj o to, aby instalacja service workerów była lekka: jeśli utrzymujesz wielu service workerów, unikaj sytuacji, w której użytkownicy ponoszą wysokie koszty instalacji za każdym razem, gdy przechodzą do nowej domeny. Innymi słowy: wstępnie zapisuj w pamięci podręcznej tylko te zasoby, które są absolutnie niezbędne.

Uprawnienia

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

Nie ma możliwości udostępniania uprawnień w różnych źródłach, 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 zachować plik cookie, aby śledzić, czy użytkownik zaakceptował uprawnienia w innej subdomenie, i uniknąć ponownego wysyłania prośby o nie.

Instalacja

Aby zainstalować PWA, każda domena musi mieć własny plik manifestu z start_url, który jest względny w stosunku do niej samej. Oznacza to, że użytkownik, który otrzyma prośbę o instalację w danym źródle (np.https://section.example.com), nie będzie mógł zainstalować progresywnej aplikacji internetowej z start_url w innym źródle (np.https://www.example.com). Innymi słowy, użytkownicy, którzy otrzymają prośbę o instalację w subdomenie, będą mogli zainstalować progresywne aplikacje internetowe tylko w przypadku podstron, a nie głównego adresu URL aplikacji.

Pojawia się też problem, że ten sam użytkownik może otrzymywać wiele próśb o instalację podczas przeglądania witryny, jeśli każda subdomena spełnia kryteria instalacji i wyświetla prośbę o zainstalowanie aplikacji PWA.

Aby złagodzić ten problem, możesz zadbać o to, aby prośba o zgodę była wyświetlana tylko w głównej domenie. Gdy użytkownik odwiedzi subdomenę, która spełnia kryteria instalacji:

1. Nasłuchuj beforeinstallprompt zdarzenia.
2. Zapobiegaj wyświetlaniu się promptu, dzwoniąc pod numer event.preventDefault().

Dzięki temu masz pewność, że prompt nie będzie wyświetlany w nieodpowiednich częściach witryny, a Ty nadal będziesz go wyświetlać np.w głównej domenie (np. na stronie głównej).

Tryb samodzielny

Podczas nawigacji w samodzielnym oknie przeglądarka będzie działać inaczej, gdy użytkownik wyjdzie poza zakres określony przez plik manifestu aplikacji PWA. Działanie zależy od wersji przeglądarki i dostawcy. Na przykład najnowsze wersje Chrome otwierają kartę niestandardową Chrome, gdy użytkownik wyjdzie poza zakres w trybie samodzielnym.

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

1. Nowy adres URL https://login.example.com może otworzyć się w elemencie iframe na pełnym ekranie.
2. Po wykonaniu zadania w elemencie iframe (np. procesu logowania) można użyć funkcji postMessage(), aby przekazać wszelkie uzyskane informacje z elementu iframe z powrotem do strony nadrzędnej.
3. Na koniec, gdy wiadomość zostanie odebrana przez stronę główną, można wyrejestrować odbiorców, a element iframe usunąć z modelu DOM.

Podsumowanie

Zasady dotyczące tego samego pochodzenia nakładają wiele ograniczeń na witryny oparte na wielu pochodzeniach, które chcą zapewnić spójne działanie PWA. Dlatego, aby zapewnić użytkownikom jak największą wygodę, zdecydowanie odradzamy dzielenie witryn na różne źródła.

W przypadku istniejących witryn, które są już w ten sposób zbudowane, prawidłowe działanie aplikacji PWA z wieloma źródłami może być trudne, ale zbadaliśmy kilka potencjalnych obejść tego problemu. Każde z nich może mieć swoje wady i zalety, więc przy wyborze metody do zastosowania w witrynie kieruj się zdrowym rozsądkiem.

Podczas oceny długoterminowej strategii 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.