Problemy i sposoby ich rozwiązania związane z tworzeniem progresywnych aplikacji internetowych w witrynach z wielu źródeł.
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 wielu 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 elementów z wielu źródeł
Istnieje kilka uzasadnionych powodów, dla których witryny używają 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 potem 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 żadnego z tych kroków, prawdopodobnie korzystanie z architektury z wieloma źródłami będzie dla Ciebie wadą 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 arbitralnego rozdzielania części witryny, które powinny być częścią jednolitego interfejsu.
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 adresemhttps://sports.example.com, sekcja polityczna pod adresemhttps://politics.example.comitd. W przypadku witryny e-commerce możesz użyć np.https://category.example.comdla kategorii produktów,https://product.example.comdla 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.comihttps://checkout.example.com.
W przypadku, gdy przeniesienie do pojedynczego źródła 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 domenach
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ć adresu register() z adresem 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 na przykład 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 jednego ź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 na prawidłowe zarządzanie 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ć w przypadku pamięci podręcznej usługi. Sprawdzone metody korzystania z bufora HTTP z użyciem usług działających w tle znajdziesz w tym poście.
Utrzymywanie niewielkiego rozmiaru instalacji: jeśli obsługujesz wiele usług workerów, nie zmuszaj użytkowników do płacenia 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 źródła https://section.example.com, nie zostanie ono przeniesione do innych źródeł, 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 poproszenie 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 instalować PWA tylko na podadresach, a nie na głównym adresie URL aplikacji.
Jest 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 z jej subdomen 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:
- Nasłuchuj zdarzenie
beforeinstallprompt. - 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 niezamierzonych częściach witryny, a Ty będziesz mieć możliwość wyświetlania go na przykład 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:
- Nowy adres URL,
https://login.example.com, może otwierać się w elementzie iframe pełnoekranowym. - Po zakończeniu zadania w elemencie iframe (np. procesu logowania) możesz użyć funkcji postMessage(), aby przekazać z niego informacje z elementu iframe z powrotem na stronę nadrzędną.
- Gdy strona główna otrzyma wiadomość, może unregisterować listenery i usunąć iframe z DOM.
Podsumowanie
Zasady dotyczące tego samego pochodzenia nakładają wiele ograniczeń na witryny tworzone na podstawie wielu źródeł, które chcą zapewnić spójne działanie PWA. Dlatego, aby zapewnić użytkownikom jak najlepszą jakość, 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ąc decyzję o tym, którego użyć w swojej witrynie, kieruj się zdrowym rozsądkiem.
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.