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

Problemy i sposoby ich rozwiązania związane z tworzeniem progresywnych aplikacji internetowych w witrynach z wielu źródeł.

Demián Renzulli

Tło

W przeszłości korzystanie z architektury wieloźródłowej miało pewne zalety, ale w przypadku progresywnych aplikacji internetowych wiąże się z wieloma wyzwaniami. W szczególności zasada tego samego pochodzenia nakłada ograniczenia na udostępnianie takich elementów jak usługi w tle i pamięci podręcznej, uprawnienia oraz na zapewnianie samodzielnego działania w różnych pochodzeniach. W tym artykule opisujemy zalety i wady korzystania z wielu źródeł oraz wyjaśniamy, jakie problemy mogą się pojawić podczas tworzenia progresywnych aplikacji internetowych w witrynach z wielu źródeł i jak sobie z nimi radzić.

Dobre i złe przykłady stosowania wielu źródeł

Istnieje kilka uzasadnionych powodów, dla których witryny korzystają z architektury wieloźródłowej. Najczęściej ma to związek z dostarczaniem niezależnego zestawu aplikacji internetowych lub tworzeniem środowisk całkowicie odizolowanych od siebie. Są też zastosowania, których należy unikać.

Dobry

Najpierw przyjrzyjmy się przydatnym powodom:

  • Lokalizacja / język: możesz użyć domeny najwyższego poziomu z kodem kraju, aby oddzielić witryny wyświetlane w różnych krajach (np. https://www.google.com.ar), lub użyć subdomen, aby podzielić witryny kierowane 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: korzystanie z różnych subdomen w celu zapewnienia funkcji, których cel znacznie różni się od celu witryny głównej. Na przykład w witrynie z wiadomościami aplikacja internetowa krzyżówek może być celowo wyświetlana z https://crosswords.example.com, a następnie instalowana 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 robisz żadnej z tych rzeczy, używanie architektury z wieloma źródłami może być niekorzystne podczas tworzenia progresywnych aplikacji internetowych.

Mimo to wiele witryn nadal jest tak sformatowanych bez konkretnego powodu lub z powodów historycznych. Przykładem jest używanie subdomen do dowolnego rozdzielania części witryny, które powinny być częścią jednolitej usługi.

Nie zalecamy stosowania takich wzorców:

  • Sekcje witryny: oddzielanie różnych sekcji witryny na subdomenach. W przypadku witryn z wiadomościami często strona główna znajduje się pod adresem https://www.example.com, a 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żyć np. https://category.example.com dla kategorii produktów, https://product.example.com dla stron produktów itp.

  • Ścieżka użytkownika: innym niewskazanym podejściem jest oddzielanie mniejszych części witryny, np. stron logowania lub ścieżek zakupu w subdomenach. Na przykład: https://login.example.com i https://checkout.example.com.

W przypadku, gdy przeniesienie na jeden adres źródłowy nie jest możliwe, poniżej znajdziesz listę problemów i (w miarę możliwości) sposobów ich obejścia, które możesz wziąć pod uwagę podczas tworzenia progresywnych aplikacji internetowych.

Problemy i rozwiązania dotyczące aplikacji PWA w różnych usługach

Podczas tworzenia witryny z wielu źródeł stworzenie jednolitej aplikacji PWA jest trudne, głównie ze względu na zasady dotyczące tego samego źródła, które narzucają pewne ograniczenia. Przyjrzyjmy się im po kolei.

Skrypty service worker

Źródło adresu URL skryptu usługi musi być takie samo jak źródło strony wywołującej funkcję register(). Oznacza to, że np. strona https://www.example.com nie może wywoływać register() za pomocą adresu URL usługi https://section.example.com.

Należy też pamiętać, że skrypt service worker może kontrolować tylko strony hostowane w ramach pochodzenia i ścieżki, do których należy. Oznacza to, że jeśli skrypt service worker jest hostowany w dodatku 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, takich jak https://section.example.com.

W tym przypadku jedynym obejściem jest użycie wielu usług (po jednej na źródło).

Pamięć podręczna

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

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

  • Korzystanie z pamięci podręcznej przeglądarki: zawsze zalecamy stosowanie tradycyjnych sprawdzonych metod dotyczących pamięci podręcznej przeglądarki. Ta metoda zapewnia dodatkową korzyść w postaci ponownego użycia zasobów z pamięci podręcznej w różnych źródłach, czego nie można zrobić z pamięcią podręczną usługi. Sprawdzone metody dotyczące używania pamięci podręcznej HTTP z usługami wtyczkowymi znajdziesz w tym poście.

  • Utrzymaj lekką instalację service workera: jeśli obsługujesz wiele service workerów, nie zmuszaj użytkowników do ponoszenia dużych kosztów instalacji za każdym razem, gdy przechodzą do nowego źródła. Innymi słowy: tylko zasoby, które są absolutnie niezbędne, są umieszczane w przedwczesnej pamięci podręcznej.

Uprawnienia

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

Ponieważ nie ma możliwości udostępniania uprawnień w różnych źródłach, jedynym rozwiązaniem jest proszenie o uprawnienia w przypadku każdej subdomeny, w której wymagana jest dana funkcja (np. lokalizacja). W przypadku powiadomień web push możesz zachować plik cookie, aby śledzić, czy użytkownik zaakceptował uprawnienia na innej subdomenie, aby nie prosić o nie ponownie.

Instalacja

Aby zainstalować PWA, każda domena musi mieć własny plik manifestu z względnym start_url. 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ć PWA 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ć PWA tylko na podstronach, a nie na głównym URL aplikacji.

Pojawia się też problem, że ten sam użytkownik może otrzymać kilka próśb o instalację podczas poruszania się po witrynie, jeśli każda z poddomen spełnia kryteria instalacji i prosi o zainstalowanie PWA.

Aby rozwiązać ten problem, możesz zadbać o to, aby prompt wyświetlał się tylko w głównym źródle. Gdy użytkownik odwiedza domenę podrzędną, która spełnia kryteria instalacji:

  1. Nasłuchuj zdarzenie beforeinstallprompt.
  2. Aby zapobiec wyświetlaniu prompta, zadzwoń pod numer event.preventDefault().

Dzięki temu będziesz mieć pewność, że prompt nie będzie wyświetlany w niepożądanych częściach witryny, a Ty będziesz mieć możliwość wyświetlania go np.w głównym źródle (np. na stronie głównej).

Tryb samodzielny

Podczas nawigacji w oknie samodzielnym przeglądarka będzie działać inaczej, gdy użytkownik wyjdzie poza zakres określony w manifeście PWA. Sposób działania zależy od wersji i producenta przeglądarki. Na przykład najnowsze wersje Chrome otwierają kartę niestandardową Chrome, gdy użytkownik opuści zakres w trybie samodzielnym.

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

  1. Nowy adres URL, https://login.example.com, może otwierać się w elementzie iframe pełnoekranowym.
  2. Po zakończeniu zadania w elemencie iframe (np. procesu logowania) możesz użyć funkcji postMessage(), aby przekazać informacje z elementu iframe z powrotem na stronę nadrzędną.
  3. Gdy wiadomość zostanie odebrana przez stronę główną, można zaniechać rejestrowania odbiorników, a element iframe można usunąć z modelu DOM.

Podsumowanie

Zasada dotycząca tego samego pochodzenia nakłada wiele ograniczeń na witryny zbudowane na podstawie wielu źródeł, które chcą zapewnić spójne działanie PWA. Dlatego, 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 źródłami może być trudne, ale znaleźliśmy kilka potencjalnych obejść. Każde z nich ma swoje wady i zalety, więc podejmuj rozsądne decyzje dotyczące tego, które z nich zastosować w swojej witrynie.

Podczas analizowania długoterminowej strategii lub przeprojektowywania witryny rozważ przeniesienie jej na pojedynczy serwer źródłowy, chyba że istnieją ważne powody, dla których warto zachować architekturę z wieloma serwerami źródłowymi.

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