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 stosowanie architektur wieloźródłowych dawało pewne korzyści, ale w przypadku progresywnych aplikacji internetowych to podejście wiązało się z wieloma wyzwaniami. W szczególności zasady dotyczące tego samego pochodzenia narzucają ograniczenia dotyczące udostępniania elementów takich jak mechanizmy Service Worker i pamięci podręczne, uprawnienia oraz możliwość korzystania z samodzielnego środowiska w wielu źródłach. W tym artykule opisujemy dobre i złe zastosowania wielu źródeł oraz podajemy wyzwania i rozwiązania związane z tworzeniem progresywnych aplikacji internetowych w witrynach z różnych domen.

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

Istnieją kilka uzasadnionych powodów, dla których witryny stosują architekturę wieloźródłową. Są to głównie po to, aby zapewniać niezależny zestaw aplikacji internetowych lub być całkowicie odizolowane od siebie. Występują też przypadki użycia, których należy unikać.

Dobry

Przyjrzyjmy się najpierw tym użytecznym przyczynom:

  • Lokalizacja / język: korzystanie z domeny krajowej najwyższego poziomu w celu rozdzielenia witryn, które mają być wyświetlane 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 oferty w określonym języku (np. https://en.wikipedia.org).

  • Niezależne aplikacje internetowe: korzystanie z różnych subdomen w celu zapewnienia obsługi, 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żami może być celowo udostępniana przez https://crosswords.example.com oraz instalowana i używana jako niezależna aplikacja PWA bez konieczności udostępniania żadnych zasobów ani funkcji głównej stronie.

Złe

Jeśli nie korzystasz z żadnych z tych rozwiązań, architektura z wielu źródeł prawdopodobnie będzie trudna w tworzeniu progresywnych aplikacji internetowych.

Pomimo tego wiele witryn nadal ma taką strukturę bez określonego powodu lub z powodu „starszej” wersji. Przykładem może być wykorzystanie subdomen w celu dowolnego rozdzielenia części witryny, które powinny być częścią ujednoliconego interfejsu.

Zdecydowanie odradzamy na przykład takie wzorce:

  • Sekcje witryny: oddzielanie różnych sekcji witryny w subdomenach. W witrynach z wiadomościami nierzadko strona główna znajduje się pod adresem https://www.example.com, sekcja sportowa znajduje się pod adresem https://sports.example.com, polityka w lokalizacji https://politics.example.com itd. W przypadku witryny e-commerce użycie tagu typu https://category.example.com w przypadku kategorii produktów, https://product.example.com dla stron produktów itd.

  • Przepływ użytkowników: odradzamy też rozdzielenie mniejszych części witryny, takich jak strony logowania czy procesy zakupu w subdomenach. np. https://login.example.com i https://checkout.example.com.

Jeśli migracja do jednego źródła nie jest możliwa, poniżej znajdziesz listę wyzwań i – tam, gdzie to możliwe – rozwiązań tymczasowych, które można rozważyć podczas tworzenia progresywnych aplikacji internetowych.

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

W przypadku tworzenia witryny z wielu źródeł zapewnienie ujednoliconej aplikacji PWA nie jest łatwym zadaniem, głównie ze względu na zasady dotyczące tego samego źródła, które nakładają 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 https://www.example.com nie może wywołać funkcji register() z adresem URL skryptu service worker pod adresem https://section.example.com.

Innym powodem jest to, ż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 jest hostowany pod adresem https://www.example.com, może kontrolować tylko adresy URL z tego źródła (na podstawie ścieżki zdefiniowanej w parametrze zakresu), ale nie będzie kontrolować żadnej strony w innych subdomenach, np. w https://section.example.com.

W tym przypadku jedynym obejściem jest użycie wielu mechanizmów Service Worker (po 1 na punkt początkowy).

Zapisywanie w pamięci podręcznej

Obiekty Cache, IndexDB i localStorage również są ograniczone do jednego punktu początkowego. Oznacza to, że nie można uzyskać dostępu do pamięci podręcznych należących do https://www.example.com, na przykład: 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:

  • Korzystaj z pamięci podręcznej przeglądarki: zawsze zalecamy korzystanie ze sprawdzonych metod dotyczących tradycyjnego buforowania przeglądarki. Ta technika ma dodatkową zaletę w postaci ponownego wykorzystania zasobów z pamięci podręcznej w różnych źródłach, czego nie można zrobić za pomocą pamięci podręcznej skryptu usługi. Sprawdzone metody korzystania z pamięci podręcznej HTTP z mechanizmami service worker znajdziesz w tym poście.

  • Uprość instalację skryptu service worker: jeśli zarządzasz wieloma skryptami service worker, unikaj płacenia przez użytkowników dużych kosztów instalacji za każdym razem, gdy przechodzą do nowego źródła. Innymi słowy: umieszczaj 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ł uprawnienie źródło https://section.example.com, nie zostanie ono przeniesione do innych źródeł, np. https://www.example.com.

Nie ma możliwości współdzielenia uprawnień między źródłami, jedynym rozwiązaniem jest poproszenie o pozwolenie w każdej subdomenie, w której wymagana jest dana funkcja (np. do lokalizacji). W przypadku np. 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 zgodę.

Instalacja

Aby zainstalować PWA, każde źródło musi mieć własny plik manifestu z atrybutem start_url względnym względem siebie. Oznacza to, że użytkownik, który otrzyma prośbę o instalację z danego źródła (tj.https://section.example.com), nie będzie mógł zainstalować aplikacji PWA z atrybutem start_url na innej stronie (np.https://www.example.com). Oznacza to, że użytkownicy, którzy otrzymają prośbę o instalację w subdomenie, będą mogli zainstalować PWA tylko dla podstron, a nie dla głównego adresu URL aplikacji.

Problemem jest też to, że podczas poruszania się po witrynie ten sam użytkownik może otrzymywać wiele próśb o instalację, jeśli każda subdomena spełnia kryteria instalacji i wyświetla użytkownikowi prośbę o zainstalowanie PWA.

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

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

Dzięki temu będziesz mieć pewność, że prompt nie wyświetla się w niezamierzonych częściach witryny, ale nadal możesz go wyświetlać, np.w głównym źródle (np. na stronie głównej).

Tryb samodzielny

Podczas poruszania się w osobnym oknie przeglądarka zachowuje się inaczej, gdy użytkownik wykroczy poza zakres ustawiony w pliku manifestu PWA. Sposób działania różni się w zależności od wersji przeglądarki i dostawcy. Na przykład najnowsze wersje Chrome otwierają niestandardową kartę Chrome, gdy użytkownik wychodzi poza zakres w trybie samodzielnym.

W większości przypadków nie ma rozwiązania, ale można zastosować obejście do niewielkich części funkcji hostowanych w subdomenach (na przykład w przepływach pracy logowania):

  1. Nowy adres URL (https://login.example.com) może się otwierać w pełnoekranowym elemencie iframe.
  2. Po ukończeniu zadania w elemencie iframe (np. w procesie logowania) można użyć funkcji postMessage() do przekazania wszelkich informacji wynikowych z elementu iframe z powrotem na stronę nadrzędną.
  3. Na koniec po odebraniu wiadomości przez stronę główną można wyrejestrować detektory i element iframe usunąć z DOM.

Podsumowanie

Zasada tej samej domeny nakłada wiele ograniczeń na witryny utworzone na podstawie wielu źródeł, które mają zapewnić spójne środowisko PWA. Z tego powodu, aby zapewnić użytkownikom maksymalną wygodę, zdecydowanie odradzamy dzielenie witryn na różne źródła.

W przypadku istniejących witryn, które już zostały utworzone w ten sposób, prawidłowe działanie aplikacji PWA korzystających z wielu źródeł może być trudne, ale przeanalizowaliśmy możliwe sposoby obejścia tego problemu. Każdy z nich może wiązać się z kompromisami, dlatego przy wyborze witryny warto kierować się własnym osądem.

Przy ocenie długoterminowej strategii lub zmian w projekcie witryny rozważ migrację do jednego źródła, chyba że ma 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.