Tworzenie wielu progresywnych aplikacji internetowych w tej samej domenie

Jak utworzyć wiele aplikacji PWA z wykorzystaniem tej samej nazwy domeny, aby poinformować użytkownika, że należy do tej samej organizacji lub tej samej usługi.

Chase Phillips
GitHub
Demián Renzulli
Matt Giuca
Matt Giuca
X GitHub

W poście na blogu z informacjami o progresywnych aplikacjach internetowych w witrynach wieloźródłowych Demian omówił wyzwania, jakie stoją przed witrynami z różnych źródeł, gdy próbują stworzyć jedną progresywną aplikację internetową, która obejmuje ich wszystkie.

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

  • Strona główna znajduje się pod adresem https://www.example.com.
  • Strony kategorii znajdują się na serwerze https://category.example.com.
  • Strony ze szczegółami produktu pod adresem https://product.example.com.

Jak wspomnieliśmy w artykule, zasady dotyczące tego samego pochodzenia nakładają kilka ograniczeń, co uniemożliwia udostępnianie mechanizmów Service Worker, pamięci podręcznych i uprawnień między źródłami. Z tego względu zdecydowanie zalecamy unikanie takiej konfiguracji oraz rozważenie w miarę możliwości migracji witryn, które już mają swoje witryny w ten sposób.

Diagram przedstawiający witrynę z różnych źródeł i pokazującą, że podczas tworzenia aplikacji PWA nie zaleca się stosowania tej techniki.
Gdy próbujesz utworzyć ujednoliconą aplikację internetową, nie używaj różnych źródeł dla sekcji tej samej witryny.

W tym poście przyjrzymy się odwrotnej sytuacji: zamiast jednej PWA z różnych źródeł przeanalizujemy przypadek firm, które chcą udostępnić wiele aplikacji PWA, korzystając z tej samej nazwy domeny, i poinformujemy użytkownika, że te aplikacje PWA należą do tej samej organizacji lub usługi.

Jak być może wiesz, wykorzystujemy różne, ale powiązane ze sobą terminy, takie jak domeny i pochodzenie. Zanim przejdziemy dalej, przyjrzyjmy się bliżej tym pojęciom.

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 odpowiadający co najmniej 1 adresowi IP. Na przykład: www.example.com jest nazwą hosta, example.com może być nazwą hosta, jeśli ma adres IP, a com nigdy nie pasuje do adresu IP, więc nigdy nie może być nazwą hosta.
  • Origin (pochodzenie): połączenie schematu, nazwy hosta i (opcjonalnie) portu. Na przykład https://www.example.com:443 jest źródłem.

Jak sama nazwa wskazuje, zasady dotyczące tego samego pochodzenia nakładają ograniczenia na pochodzenie, więc będziemy się odwoływać głównie do tego terminu w całym artykule. Niemniej jednak od czasu do czasu będziemy stosować „domeny” czy „subdomeny”, aby opisać użytą metodę i utworzyć różne „źródła”.

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

  • Witryna e-commerce chce utworzyć oddzielną witrynę, aby umożliwić sprzedawcom zarządzanie ich asortymentem, jednocześnie dbając o to, aby rozumieli, że należy ona do głównej witryny, w której użytkownicy kupują produkty.
  • Witryna z wiadomościami sportowymi chce utworzyć specjalną aplikację na potrzeby ważnego wydarzenia sportowego, aby umożliwić użytkownikom otrzymywanie w powiadomieniach o ulubionych rozgrywkach i zainstalować ją jako progresywną aplikację internetową, a jednocześnie mieć pewność, że użytkownicy rozpoznają ją jako aplikację stworzoną przez firmę medialną.
  • Pewna firma chce stworzyć osobne aplikacje do obsługi czatu, poczty i kalendarza, a potem chce, aby działały one jako osobne aplikacje powiązane z nazwą firmy.
Unikaj używania różnych źródeł dla sekcji tej samej witryny, gdy próbujesz utworzyć ujednoliconą aplikację internetową Progresive.
Firma, która jest właścicielem domeny example.com, chce udostępnić 3 niezależne aplikacje (PWA), używając tej samej nazwy domeny do nawiązania między nimi relacji.

Korzystanie z osobnych źródeł

W takich przypadkach zalecamy podejście do każdej koncepcyjnie odrębnej aplikacji na swoim pochodzeniu.

Jeśli chcesz użyć w nich tej samej nazwy domeny, możesz to zrobić, używając subdomen. Na przykład firma oferująca wiele aplikacji lub usług internetowych może hostować aplikację do poczty e-mail w domenie https://mail.example.com i aplikację kalendarza w domenie https://calendar.example.com, a jednocześnie oferować główną usługę w domenie https://www.example.com. Innym przykładem jest witryna sportowa chcąca utworzyć niezależną aplikację w pełni poświęconą ważnym wydarzeniu sportowym, takim jak mistrzostwa piłki nożnej w https://footballcup.example.com, którą użytkownicy mogą zainstalować i z niej korzystać niezależnie od głównej witryny sportowej, hostowanej pod adresem https://www.example.com. Może to być również przydatne w przypadku platform, które umożliwiają klientom tworzenie własnych niezależnych aplikacji pod marką firmy. Może to być na przykład aplikacja, która umożliwia sprzedawcom tworzenie własnych aplikacji PWA pod adresem 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, takimi jak:

  • Łatwość instalacji: każda aplikacja ma własny plik manifestu i udostępnia własny interfejs, który można zainstalować.
  • Pamięć: każda aplikacja ma własne pamięci podręczne, pamięć lokalną i w zasadzie wszystkie rodzaje pamięci lokalnej urządzenia, więc nie trzeba ich udostępniać innym.
  • Skrypty service worker: każda aplikacja ma własny skrypt service worker dla zarejestrowanych zakresów.
  • Uprawnienia: uprawnienia są też ograniczone według źródeł. Dzięki temu użytkownicy będą dokładnie wiedzieć, do której usługi przyznają uprawnienia, a funkcje takie jak powiadomienia będą poprawnie przypisywane do każdej aplikacji.

Utworzenie takiego stopnia izolacji jest najbardziej pożądane w przypadku użycia wielu niezależnych aplikacji PWA, dlatego zalecamy to podejście.

Jeśli aplikacje w subdomenach chcą udostępniać sobie dane lokalne, nadal będą mogły to robić za pomocą plików cookie. W bardziej zaawansowanych przypadkach można rozważyć synchronizację miejsca na dane przez serwer.

ALT_TEXT_HERE
Warto tworzyć różne aplikacje PWA w różnych źródłach przy użyciu subdomen.

Używanie tego samego punktu początkowego

Drugim sposobem jest tworzenie różnych PWA z tego samego źródła. Obejmuje to takie scenariusze:

Nienakładające się ścieżki

Wiele aplikacji PWA lub koncepcyjnych „aplikacji internetowych” hostowanych w tym samym źródle i niepokrywających się ścieżek. 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, a jeden z nich jest zagnieżdżony w innym:

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

Interfejs API skryptu service worker i format pliku manifestu pozwalają wykonać jedną z tych czynności z wykorzystaniem określania zakresu na poziomie ścieżki. W obu przypadkach używanie tego samego źródła wiąże się jednak z wieloma problemami i ograniczeniami, których źródło wynika z faktu, że przeglądarka nie uznaje ich w pełni za różne „aplikacje”, dlatego odradzamy takie podejście.

ALT_TEXT_HERE
Odradzamy używanie ścieżek (nakładających się lub nie) do udostępniania 2 niezależnych aplikacji PWA („app1”, „app2”) o tym samym źródle.

W następnej sekcji przeanalizujemy te wyzwania bardziej szczegółowo i zapoznamy się z tym, co można zrobić, jeśli nie da się użyć osobnych źródeł.

Wyzwania związane z wieloma aplikacjami PWA tej samej domeny

Oto kilka praktycznych problemów wspólnych w obu rozwiązaniach dotyczących tego samego pochodzenia:

  • Pamięć: pliki cookie, pamięć lokalna oraz wszelkie inne rodzaje pamięci lokalnej są współdzielone przez aplikacje. Jeśli więc użytkownik postanowi wyczyścić dane lokalne jednej aplikacji, spowoduje to wyczyszczenie wszystkich danych ze źródła. Nie można tego zrobić w przypadku pojedynczej aplikacji. Pamiętaj, że Chrome i niektóre inne przeglądarki będą aktywnie prosić użytkowników o wyczyszczenie danych lokalnych podczas odinstalowywania jednej z aplikacji. Będzie to miało wpływ na dane innych aplikacji w pierwotnym źródle. Innym problemem jest to, że aplikacje będą musiały dzielić się swoim limitem miejsca, co oznacza, że jeśli któreś z nich zajmuje za dużo miejsca, negatywnie wpłynie to na drugi.
  • Uprawnienia: są powiązane z źródłem. Oznacza to, że jeśli użytkownik przyzna uprawnienia jednej aplikacji, zostanie to też zastosowane do wszystkich aplikacji w tym źródle. Może się to wydawać przyjemne (nie musi prosić o uprawnienia wielokrotnie), ale pamiętaj: jeśli użytkownik zablokuje dostęp do jednej aplikacji, inne osoby nie będą mogły poprosić o jego uprawnienia lub skorzystać z tej funkcji.
  • Ustawienia użytkownika: ustawienia są też konfigurowane dla poszczególnych domen. Jeśli np. 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 do pozostałych aplikacji.

Ze względu na te wyzwania trudno jest promować takie podejście. Jeśli jednak nie możesz użyć osobnego źródła (np. subdomeny), o czym wspomniano w sekcji Korzystanie z osobnych źródeł, z 2 przedstawionych przez nas opcji źródła, zalecamy użycie niepokrywających się ścieżek.

Jak już wspomnieliśmy, wyzwania omówione w tej sekcji są wspólne dla obu rozwiązań. W następnej sekcji doprecyzujemy, dlaczego najmniej zalecana strategia jest stosowana po zastosowaniu pokrywających się lub zagnieżdżonych ścieżek.

Dodatkowe wyzwania dotyczące nakładających się/zagnieżdżonych ścieżek

Dodatkowy problem 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) polega na tym, że wszystkie adresy URL w aplikacji wewnętrznej są uznawane za część zarówno aplikacji zewnętrznej, jak i wewnętrznej.

W praktyce powoduje to takie problemy:

  • Promocja instalacji: jeśli użytkownik otworzy aplikację wewnętrzną (np. w przeglądarce), a aplikacja zewnętrzna jest już zainstalowana na urządzeniu użytkownika, przeglądarka nie wyświetli banerów promocyjnych instalacyjnych i nie wywoła zdarzenia przed instalacjąPromptPrompt. Wynika to z tego, że przeglądarka sprawdzi, czy bieżąca strona należy do aplikacji, która jest już zainstalowana. Rozwiązaniem jest ręczna instalacja aplikacji wewnętrznej (za pomocą opcji „Utwórz skrót” w menu przeglądarki) lub wcześniejsze zainstalowanie aplikacji wewnętrznej, przed aplikacją zewnętrzną.
  • Powiadomienie i interfejs API plakietki: jeśli zainstalowana jest aplikacja zewnętrzna, ale aplikacja wewnętrzna nie jest zainstalowana, powiadomienia i plakietki pochodzące z aplikacji wewnętrznej zostaną błędnie przypisane do aplikacji zewnętrznej (czyli do najbliższego zakresu zawartej aplikacji). Ta funkcja działa prawidłowo w przypadku, gdy obie aplikacje są zainstalowane na urządzeniu użytkownika.
  • Rejestrowanie linków: aplikacja zewnętrzna może przechwytywać adresy URL należące do aplikacji wewnętrznej. Jest tak szczególnie wtedy, gdy zainstalowana jest aplikacja zewnętrzna, a aplikacja wewnętrzna – nie. Podobnie linki w aplikacji zewnętrznej, które prowadzą do aplikacji wewnętrznej, nie będą przechwytywać linków do aplikacji wewnętrznej, ponieważ należą one do zakresu aplikacji zewnętrznej. Dodatkowo w ChromeOS i na Androidzie, jeśli takie aplikacje zostaną dodane do Sklepu Play (jako zaufane działania w internecie), aplikacja zewnętrzna będzie przechwytywać wszystkie linki. Nawet wtedy, gdy jest zainstalowana aplikacja wewnętrzna, system operacyjny nadal będzie umożliwiać użytkownikowi otwarcie jej w aplikacji zewnętrznej.

Podsumowanie

W tym artykule omówiliśmy różne sposoby tworzenia wielu progresywnych aplikacji internetowych w tej samej domenie.

Podsumowując, zdecydowanie zalecamy używanie innego źródła (np. subdomen) do hostowania niezależnych aplikacji PWA. Przechowywanie ich w tym samym pochodzeniu wiąże się z wieloma wyzwaniami, głównie dlatego, że przeglądarka nie uznaje ich w pełni za różne aplikacje.

  • Oddzielne źródła: zalecane
  • To samo źródło, nienakładające się ścieżki: niezalecane
  • Ten sam punkt początkowy, pokrywające się/zagnieżdżone ścieżki: zdecydowanie niezalecane

Jeśli nie można użyć różnych źródeł, używając niepokrywających się ścieżek (np. https://example.com/app1/ i https://example.com/app2/), zdecydowanie zalecamy użycie pokrywających się lub zagnieżdżonych ścieżek, takich jak https://example.com/ (w przypadku aplikacji zewnętrznej) i https://example.com/app/ (w przypadku aplikacji wewnętrznej).

Dodatkowe materiały

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

Fot. Tim Mossholder na stronie Unsplash