Tworzenie wielu progresywnych aplikacji internetowych w tej samej domenie

Jak tworzyć wiele PWA, korzystając z tej samej nazwy domeny, aby poinformować użytkownika, że należą one do tej samej organizacji lub usługi.

Chase Phillips

Demián Renzulli

Matt Giuca

W artykule na blogu Progresywne aplikacje internetowe w witrynach z wielu źródeł Demian omawia problemy, z którymi borykają się witryny korzystające z wielu źródeł, gdy próbują utworzyć jedną progresywną aplikację internetową, która obejmowałaby wszystkie te źródła.

Przykładem takiej architektury witryny jest witryna e-commerce, w której:

• Strona główna znajduje się pod adresem https://www.example.com.
• Strony kategorii są hostowane pod adresem https://category.example.com.
• strony ze szczegółami produktów na stronie https://product.example.com.

Jak wspomniano w artykule, zasada tego samego pochodzenia nakłada kilka ograniczeń, które uniemożliwiają udostępnianie usług, pamięci podręcznej i uprawnień między pochodzeniem. Dlatego zdecydowanie zalecamy unikanie tego typu konfiguracji, a w przypadku witryn już utworzonych w ten sposób – rozważenie przejścia na architekturę witryny z jednym źródłem, o ile to możliwe.

W tym artykule omawiamy odwrotną sytuację: zamiast jednej PWA w różnych domenach omówimy przypadek firm, które chcą udostępniać wiele PWA, korzystając z tej samej nazwy domeny i informując użytkownika, że te PWA należą do tej samej organizacji lub usługi.

Jak już pewnie zauważyłeś/zauważyłaś, używamy różnych, ale powiązanych ze sobą terminów, takich jak domeny i źródła. Zanim przejdziesz dalej, zapoznaj się z tymi pojęciami.

Terminy techniczne

• Domena: dowolna sekwencja etykiet zdefiniowana w systemie nazw domenowych (DNS). Na przykład: com i example.com to domeny.
• Nazwa hosta: wpis DNS, który odpowiada co najmniej 1 adresowi IP. Na przykład: www.example.com to nazwa hosta, example.com może być nazwą hosta, jeśli ma adres IP, a com nigdy nie zostanie rozpoznana jako adres IP, więc nigdy nie może być nazwą hosta.
• Źródło:połączenie schematu, nazwy hosta i (opcjonalnie) portu. Na przykład https://www.example.com:443 to punkt początkowy.

Jak wskazuje nazwa, zasada dotycząca tego samego źródła nakłada ograniczenia na źródła, dlatego w tym artykule będziemy głównie używać tego terminu. Mimo to od czasu do czasu będziemy używać terminów „domeny” lub „subdomeny”, aby opisać używaną technikę, która umożliwia tworzenie różnych „źródeł”.

Argumenty za tworzeniem wielu powiązanych Progressive Web Apps

W niektórych przypadkach możesz chcieć tworzyć aplikacje niezależne, ale nadal identyfikować je jako należące do tej samej organizacji lub „marki”. Ponowne użycie tej samej nazwy domeny to dobry sposób na ustanowienie takiej relacji. Na przykład:

• Witryna e-commerce chce stworzyć samodzielne narzędzie, które pozwoli sprzedawcom zarządzać asortymentem, a jednocześnie zapewni im świadomość, że należy on do głównej witryny, w której użytkownicy kupują produkty.
• Witryna z informacjami sportowymi chce utworzyć aplikację na konkretne ważne wydarzenie sportowe, aby użytkownicy mogli otrzymywać statystyki dotyczące swoich ulubionych rozgrywek w powiadomieniach. Aplikacja ma być instalowana jako aplikacja Progressive Web, a użytkownicy mają ją rozpoznawać jako aplikację stworzoną przez firmę zajmującą się wiadomościami.
• Firma chce tworzyć osobne aplikacje do czatu, poczty i kalendarza, które mają działać jako osobne aplikacje powiązane z nazwą firmy.

Używanie oddzielnych źródeł

W takich przypadkach zalecamy, aby każda aplikacja, która jest odrębna pod względem koncepcyjnym, działała na własnym adresie.

Jeśli chcesz używać tej samej nazwy domeny we wszystkich tych domenach, możesz to zrobić, korzystając z subdomen. Na przykład firma, która udostępnia wiele aplikacji lub usług internetowych, może hostować aplikację pocztową pod adresem https://mail.example.com, a aplikację kalendarza pod adresem https://calendar.example.com, oferując jednocześnie główną usługę swojej firmy pod adresem https://www.example.com. Innym przykładem jest strona sportowa, która chce utworzyć niezależną aplikację poświęconą ważnemu wydarzeniu sportowemu, np. mistrzostwom świata w piłce nożnej, które użytkownicy mogą zainstalować i korzystać z niej niezależnie od głównej strony sportowej, hostowanej pod adresem https://www.example.com.https://footballcup.example.com Takie podejście może być też przydatne w przypadku platform, które umożliwiają klientom tworzenie własnych aplikacji pod marką firmy. Na przykład aplikacja, która umożliwia sprzedawcom tworzenie własnych PWA na stronie https://merchant1.example.com, https://merchant2.example.com itp.

Używanie różnych źródeł zapewnia izolację między aplikacjami, co oznacza, że każda z nich może niezależnie zarządzać różnymi funkcjami przeglądarki, w tym:

• Możliwość instalacji: każda aplikacja ma własny plik manifestu i własny proces instalacji.
• Pamięć: każda aplikacja ma własne pamięci podręczne, pamięć lokalną i generalnie wszystkie formy pamięci lokalnej urządzenia, bez udostępniania ich innym.
• Usługa Service Worker: każda aplikacja ma własnego pracownika usługi dla zarejestrowanych zakresów.
• Uprawnienia: uprawnienia są również ograniczone do źródeł. Dzięki temu użytkownicy będą dokładnie wiedzieć, które usługi będą miały dostęp do ich danych, a funkcje takie jak powiadomienia będą przypisane do odpowiednich aplikacji.

Utworzenie takiej izolacji jest najbardziej pożądane w przypadku wielu niezależnych Progressive Web Apps, dlatego zdecydowanie zalecamy to podejście.

Jeśli aplikacje na subdomenach chcą udostępniać sobie dane lokalne, nadal będą mogły to robić za pomocą plików cookie. W bardziej zaawansowanych scenariuszach mogą też synchronizować pamięć za pomocą serwera.

Korzystanie z tego samego źródła

Drugie podejście polega na tworzeniu różnych PWA w ramach tej samej domeny. Dotyczy to tych scenariuszy:

Ścieżki nienakładające się

Wiele aplikacji PWA lub koncepcyjnych „aplikacji internetowych” hostowanych w tym samym źródle z ścieżkami, które się nie nakładają. Na przykład:

• https://example.com/app1/
• https://example.com/app2/

Ścieżki nakładające się lub zagnieżdżone

Wiele PWAs na tym samym pochodzeniu, z których jeden ma zakres zagnieżdżony w drugim:

• https://example.com/ („aplikacja zewnętrzna”)
• https://example.com/app/ („aplikacja wewnętrzna”)

Interfejs API skryptu service worker i format pliku manifestu umożliwiają wykonanie którejkolwiek z tych czynności za pomocą ograniczania zakresu do poziomu ścieżki. Jednak w obu przypadkach korzystanie z tego samego źródła wiąże się z wielu problemami i ograniczeniami, które wynikają z tego, że przeglądarka nie będzie traktować tych aplikacji jako odrębnych. Nie zalecamy takiego podejścia.

W następnej sekcji szczegółowo omówimy te problemy i wyjaśnimy, co można zrobić, jeśli korzystanie z oddzielnych źródeł nie wchodzi w grę.

Problemy związane z wieloma PWA z tego samego źródła

Oto kilka praktycznych problemów wspólnych dla obu metod:

• Pamięć: pliki cookie, pamięć lokalna i wszystkie formy pamięci lokalnej na urządzeniu są udostępniane aplikacjom. Dlatego jeśli użytkownik zdecyduje się usunąć dane lokalne jednej aplikacji, zostaną one usunięte ze wszystkich aplikacji. Nie ma możliwości usunięcia danych tylko z jednej aplikacji. Pamiętaj, że Chrome i niektóre inne przeglądarki będą aktywnie prosić użytkowników o usunięcie danych lokalnych podczas odinstalowywania jednej aplikacji, co będzie miało wpływ na dane z innych aplikacji. Kolejnym problemem jest to, że aplikacje będą musiały dzielić limit miejsca na dane, co oznacza, że jeśli jedna z nich zajmie zbyt dużo miejsca, druga będzie na tym ucierpieć.
• Uprawnienia: uprawnienia przeglądarki są powiązane ze źródłem. Oznacza to, że jeśli użytkownik przyzna uprawnienia jednej aplikacji, zostaną one zastosowane do wszystkich aplikacji tego pochodzenia jednocześnie. Może się to wydawać dobrą rzeczą (nie trzeba prosić o uprawnienia kilka razy), ale pamiętaj, że jeśli użytkownik zablokuje uprawnienia dla jednej aplikacji, inne aplikacje nie będą mogły prosić o te uprawnienia ani korzystać z tej funkcji. Pamiętaj, że nawet jeśli uprawnienia przeglądarki należy przyznać tylko raz na źródło, uprawnienia na poziomie systemu należy przyznać raz na aplikację, niezależnie od tego, czy wiele aplikacji wskazuje to samo źródło.
• Ustawienia użytkownika: ustawienia są też ustawiane dla każdej domeny. Jeśli na przykład 2 aplikacje mają różne rozmiary czcionek, a użytkownik chce dostosować powiększenie tylko w jednej z nich, nie będzie mógł tego zrobić bez zastosowania tego ustawienia również w innych aplikacjach.

Te problemy utrudniają zachęcanie do takiego podejścia. Jeśli jednak nie możesz użyć oddzielnego źródła (np. domeny podrzędnej), jak opisano w sekcji Używanie oddzielnych źródeł, z dwóch przedstawionych przez nas opcji dotyczących źródeł o tych samych nazwach zdecydowanie zalecamy użycie ścieżek nienakładających się na siebie zamiast ścieżek nakładających się na siebie lub zagnieżdżonych.

Jak już wspomnieliśmy, problemy omawiane w tej sekcji dotyczą obu metod opartych na tym samym źródle. W następnej sekcji omówimy szczegółowo, dlaczego używanie ścieżek nakładających się lub zagnieżdżonych jest najmniej zalecaną strategią.

Dodatkowe problemy w przypadku ścieżek nakładających się lub zagnieżdżonych

Dodatkowym problemem związanym z ścieżkami nakładających się lub zagnieżdżonych (gdzie https://example.com/ to aplikacja zewnętrzna, a https://example.com/app/ to aplikacja wewnętrzna) jest to, że wszystkie adresy URL w aplikacji wewnętrznej będą traktowane jako część zarówno aplikacji zewnętrznej, jak i aplikacji wewnętrznej.

W praktyce powoduje to następujące problemy:

• Promocja instalacji: jeśli użytkownik otworzy aplikację wewnętrzną (np. w przeglądarce), gdy aplikacja zewnętrzna jest już zainstalowana na jego urządzeniu, przeglądarka nie będzie wyświetlać banerów promocyjnych dotyczących instalacji, a zdarzenie BeforeInstallPrompt nie zostanie uruchomione. Dzieje się tak, ponieważ przeglądarka sprawdza, czy bieżąca strona należy do zainstalowanej już aplikacji, i uznaje, że tak jest. Aby obejść ten problem, zainstaluj aplikację wewnętrzną ręcznie (za pomocą opcji „Utwórz skrót” w menu przeglądarki) lub zainstaluj najpierw aplikację wewnętrzną, a potem zewnętrzną.
• Powiadomienia i interfejs API do generowania plakietek: jeśli aplikacja zewnętrzna jest zainstalowana, ale aplikacja wewnętrzna nie, powiadomienia i plakietki pochodzące z aplikacji wewnętrznej zostaną błędnie przypisane do aplikacji zewnętrznej (która jest najbliższym zakresem zainstalowanej aplikacji). Ta funkcja działa prawidłowo, gdy obie aplikacje są zainstalowane na urządzeniu użytkownika.
• Link Przechwytywanie: aplikacja zewnętrzna może przechwytywać adresy URL należące do aplikacji wewnętrznej. Jest to szczególnie prawdopodobne, jeśli aplikacja zewnętrzna jest zainstalowana, a wewnętrzna nie. Podobnie linki w aplikacji zewnętrznej, które odsyłają do aplikacji wewnętrznej, nie będą przechwytywane przez aplikację wewnętrzną, ponieważ są uważane za znajdujące się w zakresie aplikacji zewnętrznej. Dodatkowo na ChromeOS i Androidzie, jeśli te aplikacje są dodane do Sklepu Play (jako zaufane działania internetowe), aplikacja zewnętrzna będzie przechwytywać wszystkie linki. Nawet jeśli wewnętrzna aplikacja jest zainstalowana, system operacyjny nadal będzie oferować użytkownikowi możliwość otwarcia ich w zewnętrznej aplikacji.

Podsumowanie

W tym artykule omawiamy różne sposoby, dzięki którym deweloperzy mogą tworzyć wiele powiązanych ze sobą progresywnych aplikacji internetowych w ramach tej samej domeny.

Podsumowując, zdecydowanie zalecamy używanie innego źródła (np. za pomocą subdomen) do hostowania niezależnych Progressive Web Apps. Hostowanie ich w tym samym źródle wiąże się z wielu wyzwaniami, głównie dlatego, że przeglądarka nie będzie traktować ich jako odrębnych aplikacji.

• Oddzielne źródła: zalecane
• Te same źródła, nienakładające się ścieżki: niezalecane
• Ten sam origin, ścieżki nakładające się lub zagnieżdżone: zdecydowanie niezalecane

Jeśli nie można użyć różnych źródeł, zalecamy używanie ścieżek, które się nie nakładają (np.https://example.com/app1/ i https://example.com/app2/), zamiast ścieżek nakładających się lub zagnieżdżonych, np. https://example.com/ (dla aplikacji zewnętrznej) i https://example.com/app/ (dla aplikacji wewnętrznej).

Dodatkowe materiały

• Progresywne aplikacje internetowe na stronach wieloźródłowych

Dziękujemy za opinie i sugestie techniczne: Joe Medley, Dominick Ng, Alan Cutter, Daniel Murphy, Penny McLachlan, Thomas Steiner i Darwin Huang

Zdjęcie autorstwa Tim Mossholder ze strony Unsplash