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

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

Demián Renzulli

Wprowadzenie

W przeszłości korzystanie z architektur wieloźródłowych dawało kilka korzyści, ale w przypadku progresywnych aplikacji internetowych wiąże się to z wieloma wyzwaniami. W szczególności zasady dotyczące tego samego pochodzenia nakładają ograniczenia na udostępnianie elementów takich jak mechanizmy Service Worker, pamięci podręczne i uprawnienia, a także w celu zapewnienia oddzielnych funkcji w różnych źródłach. W tym artykule omówimy dobre i złe zastosowania różnych źródeł oraz wyzwania i obejścia związane z tworzeniem progresywnych aplikacji internetowych w witrynach wieloźródłowych.

Dobre i złe zastosowania wielu źródeł

Istnieje kilka uzasadnionych powodów, dla których warto stosować w witrynach architekturę wieloźródłową, przeważnie związanych z udostępnianiem niezależnego zestawu aplikacji internetowych lub tworzeniem funkcji całkowicie odizolowanych od siebie. Istnieją też przypadki użycia, których należy unikać.

Dobry

Przyjrzyjmy się najpierw użytecznym przyczynom:

  • Lokalizacja / język: używanie domeny najwyższego poziomu z kodem kraju do oddzielania witryn wyświetlanych w różnych krajach (np. https://www.google.com.ar) lub używania subdomen do podziału witryn kierowanych na różne lokalizacje (np. https://newyork.craigslist.org) lub proponowanie treści w konkretnym języku (np. https://en.wikipedia.org).

  • Niezależne aplikacje internetowe: korzystanie z różnych subdomen w celu udostępniania treści, których przeznaczenie znacznie różni się od przeznaczenia witryny w głównym źródle. Na przykład w witrynie z wiadomościami aplikacja internetowa z krzyżownikami może być celowo wyświetlana z poziomu https://crosswords.example.com oraz zainstalowana i używana jako niezależna aplikacja PWA bez konieczności udostępniania żadnych zasobów ani funkcji witrynie głównej.

Złe

Jeśli nie wykonujesz żadnej z tych czynności, podczas tworzenia progresywnych aplikacji internetowych prawdopodobnie użycie architektury wieloźródłowej będzie niekorzystne.

Pomimo tego wiele witryn ma taką strukturę bez konkretnego powodu lub z powodów „starszych”. Jednym z przykładów jest użycie subdomen do dowolnych części witryny, które powinny stanowić część ujednoliconego interfejsu.

Stanowczo odradzamy na przykład takie wzorce:

  • Sekcje witryny: rozdzielanie różnych sekcji witryny w subdomenach. W witrynach z wiadomościami często wyświetla się strona główna pod adresem: https://www.example.com, dział sportowy – https://sports.example.com, polityka – https://politics.example.com itd. W przypadku witryny e-commerce możesz użyć takiego identyfikatora jak https://category.example.com dla kategorii produktów, https://product.example.com dla stron produktów itp.

  • Przepływ użytkowników: także odradzamy oddzielenie różnych mniejszych części witryny, takich jak strony logowania czy etapy zakupu w subdomenach. np. https://login.example.com i https://checkout.example.com.

W przypadku, gdy migracja do jednego źródła jest niemożliwa, poniżej przedstawiamy listę wyzwań oraz (jeśli to możliwe) rozwiązania, które można zastosować podczas tworzenia progresywnych aplikacji internetowych.

Wyzwania i obejścia PWA z różnych źródeł

Gdy tworzysz witrynę w wielu źródłach, zapewnienie ujednoliconej wersji PWA jest trudnym zadaniem, głównie z powodu zasady dotyczącej tego samego pochodzenia, która nakłada kilka ograniczeń. Przyjrzyjmy się im pojedynczo.

Skrypty service worker

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

Pamiętaj też, że skrypt service worker może kontrolować tylko strony hostowane w źródle i ścieżce, do której należy. Oznacza to, że jeśli skrypt service worker znajduje się w domenie https://www.example.com, może kontrolować tylko adresy URL z tego źródła (zgodnie ze ścieżką określoną w parametrze zakresu), ale nie kontroluje żadnej strony w innych subdomenach, np. w tagu https://section.example.com.

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

Zapisywanie w pamięci podręcznej

Obiekt Cache, indexDB i localStorage również są 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 czynności, które możesz wykonać, aby prawidłowo zarządzać pamięciami podręcznymi w takich sytuacjach:

  • Korzystanie z pamięci podręcznej przeglądarki: zawsze zalecamy korzystanie ze sprawdzonych metod dotyczących tradycyjnego zapisywania plików w pamięci podręcznej przeglądarki. Ta metoda zapewnia dodatkową korzyść w postaci ponownego wykorzystania zasobów z pamięci podręcznej w różnych źródłach, co jest niemożliwe w przypadku pamięci podręcznej skryptu service worker. Sprawdzone metody używania pamięci podręcznej HTTP z skryptami service worker znajdziesz w tym poście.

  • Łagodność instalacji skryptu service worker: jeśli korzystasz z wielu mechanizmów Service Worker, nie każ użytkownikom płacić dużych kosztów instalacji za każdym razem, gdy przechodzą do nowego źródła. Innymi słowy, buforuj tylko te zasoby, które są absolutnie konieczne.

Uprawnienia

Uprawnienia są też ograniczone do źródeł. Oznacza to, że jeśli użytkownik przyznał uprawnienia do źródła https://section.example.com, nie zostaną one przeniesione do innych źródeł, takich jak https://www.example.com.

Nie ma możliwości współdzielenia uprawnień między źródłami, dlatego jedynym rozwiązaniem jest poproszenie o zgodę w każdej subdomenie, w której wymagana jest dana funkcja (np. lokalizacja). W przypadku takich funkcji jak web push możesz przechowywać plik cookie, by śledzić, czy dane uprawnienie zostało zaakceptowane przez użytkownika w innej subdomenie, i w ten sposób uniknąć ponownego wysyłania prośby o nie.

Instalacja

Aby można było zainstalować PWA, każde źródło musi mieć własny plik manifestu z atrybutem start_url względem siebie. Oznacza to, że użytkownik otrzymujący prośbę o instalację w danym źródle (np.https://section.example.com) nie będzie mógł zainstalować aplikacji PWA z start_url w innym (np.https://www.example.com). Inaczej mówiąc, użytkownicy otrzymujący prośbę o instalację w subdomenie nie będą mogli zainstalować aplikacji PWA z inną aplikacją.

Ten sam użytkownik może też otrzymać wiele próśb o instalację podczas poruszania się po witrynie, jeśli każda subdomena spełnia kryteria instalacji, a użytkownik może zobaczyć prośbę o zainstalowanie aplikacji PWA.

Aby uniknąć tego problemu, możesz upewnić się, że prompt wyświetla się tylko w głównym źródle. Gdy użytkownik odwiedza subdomenę, która spełnia kryteria instalacji:

  1. Posłuchaj zdarzenia beforeinstallprompt.
  2. Zablokuj wyświetlanie potwierdzenia, dzwoniąc pod numer event.preventDefault().

Dzięki temu prompt nie będzie wyświetlany w niezamierzonych częściach witryny, a jednocześnie nadal będzie można go wyświetlać, na przykład w głównej aplikacji (np. na stronie głównej).

Tryb samodzielny

Podczas nawigowania w samodzielnym oknie przeglądarka zachowuje się inaczej, gdy użytkownik wykracza poza zakres ustawiony w pliku manifestu aplikacji PWA. Działanie zależy od wersji przeglądarki i dostawcy. Na przykład w najnowszych wersjach Chrome otwiera się niestandardowa karta Chrome, gdy użytkownik wychodzi poza zakres w trybie samodzielnym.

W większości przypadków nie ma rozwiązania, które byłoby rozwiązaniem tego problemu, ale można je obejść w przypadku niewielkiej części interfejsu hostowanej w subdomenach (na przykład w procesach logowania):

  1. Nowy adres URL – https://login.example.com – może się otworzyć w pełnoekranowym elemencie iframe.
  2. Gdy zadanie zostanie wykonane w elemencie iframe (np. podczas procesu logowania), można użyć funkcji postMessage(), by przekazać wszelkie uzyskane informacje z elementu iframe z powrotem na stronę nadrzędną.
  3. Na koniec, gdy wiadomość trafi na stronę główną, można wyłączyć detektory i usunąć element iframe z DOM.

Podsumowanie

Zasady dotyczące tego samego pochodzenia nakładają wiele ograniczeń w przypadku witryn tworzonych na podstawie różnych źródeł, które chcą zapewnić spójne wrażenia użytkowników PWA. Z tego względu w trosce o wygodę użytkowników odradzamy dzielenie witryn na różne źródła.

W przypadku istniejących witryn, które są już w ten sposób utworzone, poprawne działanie wieloźródłowej aplikacji PWA może być trudne, ale zbadaliśmy kilka potencjalnych rozwiązań. Każda z tych metod może wiązać się z wadami, dlatego przy podejmowaniu decyzji o tym, którą strategię zastosować na stronie, kieruj się rozsądkiem.

Zastanawiając się nad długoterminową strategią lub zmianą wyglądu witryny, rozważ migrację do jednego źródła, chyba że istnieje ważny powód, aby zachować architekturę wieloźródłową.

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