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 wieloma źródłami 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 wspomnieliśmy w artykule, zasada Same-origin nakłada kilka ograniczeń, które uniemożliwiają udostępnianie instancji roboczych usługi, pamięci podręcznej i uprawnień między źródłami. 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.

Podczas tworzenia ujednoliconej progresywnej aplikacji internetowej nie używaj różnych źródeł dla sekcji tej samej witryny.

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

Używamy różnych, powiązanych ze sobą haseł, np. domen i źródeł. 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.
• Origin: kombinacja 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”. Dobrym sposobem na nawiązanie relacji jest ponowne użycie tej samej nazwy domeny. Na przykład:

• Witryna e-commerce chce stworzyć osobną stronę, która pozwoli sprzedawcom zarządzać ich asortymentem, a jednocześnie zapewni im świadomość, że należy ona 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 progresywna aplikacja internetowa, 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.

Firma, która jest właścicielem domeny example.com, chce udostępnić 3 niezależne aplikacje lub progresywne aplikacje internetowe, używając tej samej nazwy domeny, aby utworzyć między nimi relację.

Używanie oddzielnych źródeł

W takich przypadkach zalecamy, aby każda aplikacja, która jest odrębna pod względem koncepcyjnym, była dostępna w ramach własnego źródła.

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 oferująca wiele aplikacji i usług internetowych może hostować aplikację pocztową pod adresem https://mail.example.com i aplikację kalendarzową pod adresem https://calendar.example.com, a główną usługę – https://www.example.com. Innym przykładem jest witryna o sporcie, która chce stworzyć niezależną aplikację w pełni poświęconą ważnemu wydarzeniu sportowemu, takiemu jak mistrzostwa piłki nożnej na stadionie https://footballcup.example.com, którą użytkownicy mogą zainstalować i z niej korzystać niezależnie od głównej witryny sportowej, która jest dostępna na stronie https://www.example.com. Takie podejście może być przydatne również w przypadku platform, które pozwalają klientom tworzyć własne, niezależne aplikacje 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 można ją zainstalować.
• 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.
• Workery usług: każda aplikacja ma własnego workera usługi dla zarejestrowanych zakresów.
• Uprawnienia: zakres uprawnień zależy też od źródła. Dzięki temu użytkownicy będą dokładnie wiedzieć, do której usługi przyznają uprawnienia, a funkcje takie jak powiadomienia będą odpowiednio przypisywane do każdej 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.

Budowanie różnych PWA w różnych źródłach za pomocą subdomen to dobra praktyka.

Używanie tego samego punktu początkowego

Drugie podejście polega na tworzeniu różnych PWA w ramach tej samej domeny. Obejmuje to następujące scenariusze:

Ścieżki nienakładające się

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

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

Nakładające się/zagnieżdżone ścieżki

Wiele aplikacji PWA w tym samym źródle, których zakres jest 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órejś 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.

Nie zalecamy stosowania ścieżek (nakładających się lub nie) w celu dostarczania 2 niezależnych aplikacji PWA („app1” lub „app2”) o tym samym pochodzeniu.

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

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

Oto kilka praktycznych problemów typowych dla obu metod stosowanych w przypadku tej samej domeny:

• Pamięć: pliki cookie, pamięć lokalna oraz wszelkie formy pamięci lokalnej urządzenia są współdzielone przez aplikacje. Dlatego jeśli użytkownik zdecyduje się usunąć dane lokalne jednej aplikacji, zostaną one usunięte ze wszystkich aplikacji z tego źródła. 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 wpłynie również na dane z innych aplikacji z tego źródła. 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 tego samego źródła zdecydowanie zalecamy użycie ścieżek nienakładających się zamiast ścieżek nakładających się 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 szczegółowo wyjaśnimy, 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 podejściem z nakładającymi się lub zagnieżdżonymi ścieżkami (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ą uważane za 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 tworzenia 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.
• Rejestrowanie linków: aplikacja zewnętrzna może rejestrować adresy URL należące do aplikacji wewnętrznej. Zwłaszcza wtedy, gdy zainstalowana jest zewnętrzna aplikacja, a aplikacja 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. Poza tym w ChromeOS i Androidzie, jeśli te aplikacje zostaną dodane do Sklepu Play (jako zaufane działania internetowe), aplikacja zewnętrzna przechwytuje wszystkie linki. Nawet jeśli wewnętrzna aplikacja jest zainstalowana, system operacyjny nadal będzie oferować użytkownikowi możliwość otwarcia aplikacji zewnętrznej.

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 aplikacji PWA. 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
• Ścieżki z tego samego źródła, które się nie pokrywają: niezalecane
• Ten sam punkt początkowy, ścieżki nakładające się/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