Aynı etki alanında birden çok Aşamalı Web Uygulaması oluşturma

Çok kaynaklı sitelerde Progresif Web Uygulamaları blog gönderisinde Demian, birden çok kaynakta inşa edilen sitelerin hepsini kapsayan tek bir Progresif Web Uygulaması oluşturmaya çalışırken karşılaştıkları zorlukları tartıştı.

Bu tür site mimarisine bir örnek, aşağıdaki özelliklere sahip bir e-ticaret sitesidir:

• Ana sayfa şu adreste: https://www.example.com.
• Kategori sayfaları şu adreste barındırılır: https://category.example.com.
• adresindeki ürün detay sayfaları https://product.example.com.

Makalede tartışıldığı gibi, aynı kaynak politikası hizmet çalışanlarının, önbelleklerin ve izinlerin kaynaklar arasında paylaşılmasını engelleyen çeşitli kısıtlamalar getirir. Bu nedenle, bu tür bir yapılandırmadan kaçınmanızı ve halihazırda bu şekilde oluşturulmuş sitelere sahip olanların, mümkün olduğunda tek bir kaynak site mimarisine geçmeyi düşünmelerini şiddetle tavsiye ederiz.

Bu gönderide, tam tersi duruma bir göz atacağız: Farklı kaynaklarda tek bir PWA yerine, sağlamak isteyen şirketlerin durumunu analiz edeceğiz. çoklu PWA’laraynı olanaklardan yararlanarak alan adıve kullanıcının bu PWA’ların aynı kuruluşa veya hizmete ait olduğunu bilmesini sağlayın.

Fark etmiş olabileceğiniz gibi, alanlar ve kökenler gibi farklı ancak birbiriyle ilişkili terimler kullanıyoruz. Devam etmeden önce, bu kavramları gözden geçirelim.

Teknik terimler #

• İhtisas: Etki Alanı Adı Sisteminde (DNS) tanımlanan herhangi bir etiket dizisi. Örneğin: com Ve example.com etki alanlarıdır.
• Ana bilgisayar adı: En az bir IP adresine çözümlenen bir DNS girişi. Örneğin: www.example.com bir ana bilgisayar adı olurdu, example.com bir IP adresi varsa bir ana bilgisayar adı olabilir ve com asla bir IP adresine çözümlenmez ve bu nedenle asla bir ana bilgisayar adı olamaz.
• Menşei: Bir şema, ana bilgisayar adı ve (isteğe bağlı olarak) bağlantı noktasının birleşimi. Örneğin, bir kökendir.

Adından da anlaşılacağı gibi, aynı kaynak politikası kökenlere kısıtlamalar getirir, bu nedenle makale boyunca terime çoğunlukla atıfta bulunacağız. Bununla birlikte, farklı “orijinler” yaratmak için kullanılan tekniği tanımlamak için zaman zaman “etki alanları” veya “alt alanlar” kullanacağız.

Bazı durumlarda, bağımsız uygulamalar oluşturmak isteyebilirsiniz, ancak bunları yine de aynı kuruluşa veya “markaya” ait olarak tanımlayabilirsiniz. Aynısını tekrar kullanmak alan adı bu ilişkiyi kurmanın iyi bir yoludur. Örneğin:

• Bir e-ticaret sitesi, satıcıların envanterlerini yönetmelerine izin verirken bunun kullanıcıların ürünleri satın aldığı ana web sitesine ait olduğunu anlamalarını sağlamak için bağımsız bir deneyim oluşturmak istiyor.
• Bir spor haber sitesi, kullanıcıların en sevdikleri müsabakalarla ilgili istatistikleri bildirimler yoluyla almasına izin vermek ve bunu bir Progresif Web Uygulaması olarak yüklemek ve aynı zamanda kullanıcıların bunu bir uygulama olarak tanımasını sağlamak için büyük bir spor etkinliği için özel bir uygulama oluşturmak istiyor. haber şirketi.
• Bir şirket, ayrı sohbet, posta ve takvim uygulamaları oluşturmak istiyor ve bunların şirket adına bağlı olarak ayrı uygulamalar olarak çalışmasını istiyor.

Ayrı kökenleri kullanma #

Bu gibi durumlarda önerilen yaklaşım, kendi kaynağında yaşayan kavramsal olarak farklı her uygulama içindir.

Hepsinin içinde aynı alan adını kullanmak istiyorsanız, bunu alt alan adlarını kullanarak yapabilirsiniz. Örneğin, birden çok internet uygulaması veya hizmeti sağlayan bir şirket, şu adreste bir posta uygulaması barındırabilir: ve bir takvim uygulaması https://calendar.example.comişletmelerinin ana hizmetini sunarken, https://www.example.com. Başka bir örnek, bir futbol şampiyonası gibi tamamen önemli bir spor etkinliğine adanmış bağımsız bir uygulama oluşturmak isteyen bir spor sitesidir. https://footballcup.example.comkullanıcıların şu adreste barındırılan ana spor sitesinden bağımsız olarak yükleyip kullanabilecekleri: https://www.example.com. Bu yaklaşım, müşterilerin şirketin markası altında kendi bağımsız uygulamalarını oluşturmasına izin veren platformlar için de yararlı olabilir. Örneğin, satıcıların kendi PWA’larını https://merchant1.example.com, https://merchant2.example.comvesaire.

Farklı kökenlerin kullanılması, uygulamalar arasında izolasyon sağlar, bu da her birinin farklı tarayıcı özelliklerini bağımsız olarak yönetebileceği anlamına gelir, örneğin:

• Kurulabilirlik: Her uygulamanın kendi Manifest’i vardır ve kendi yüklenebilir deneyimini sunar.
• Depolamak: Her uygulamanın kendi önbellekleri, yerel depolaması ve temel olarak tüm cihaz yerel depolama biçimleri vardır, bunları başkalarıyla paylaşmadan.
• Servis Çalışanları: Her uygulamanın, kayıtlı kapsamlar için kendi hizmet çalışanı vardır.
• İzinler: İzinler de kaynaklara göre kapsam dahilindedir. Bu sayede kullanıcılar hangi hizmete izin verdiklerini tam olarak bilecek ve bildirimler gibi özellikler her uygulamaya uygun şekilde atanacak.

Böyle bir izolasyon derecesi oluşturmak, çoklu, bağımsız PWA’ların kullanım durumunda en çok istenen şeydir, bu nedenle bu yaklaşımı şiddetle tavsiye ediyoruz.

Alt alan adlarındaki uygulamalar yerel verileri birbirleriyle paylaşmak isterse, bunu yine de tanımlama bilgileri aracılığıyla yapabilirler veya daha gelişmiş senaryolar için depolamayı bir sunucu aracılığıyla senkronize etmeyi düşünebilirler.

Aynı orijini kullanmak #

İkinci yaklaşım, farklı PWA’ları aynı kaynak üzerinde oluşturmaktır. Bu, aşağıdaki senaryoları içerir:

Çakışmayan yollar #

Aynı kaynakta barındırılan ve yolları örtüşmeyen birden çok PWA veya kavramsal “web uygulaması”. Örneğin:

• app1/
• app2/

Çakışan/iç içe geçmiş yollar #

Aynı kaynak üzerinde, biri diğerinin içine yerleştirilmiş birden fazla PWA:

• (“dış uygulama”)
• app/ (“iç uygulama”)

Hizmet çalışanı API’si ve bildirim biçimi, yol düzeyinde kapsam belirleme kullanarak yukarıdakilerden herhangi birini yapmanıza olanak tanır. Bununla birlikte, her iki durumda da, aynı kaynağın kullanılması birçok sorun ve sınırlama getirir; bunların kökü, tarayıcının bunları tamamen farklı “uygulamalar” olarak kabul etmeyeceği gerçeğinden kaynaklanır, bu nedenle bu yaklaşım tavsiye edilmez.

Bir sonraki bölümde, bu zorlukları ve ayrı kaynaklar kullanmak bir seçenek değilse neler yapılabileceğini daha ayrıntılı olarak analiz edeceğiz.

Çoklu, aynı kaynaklı PWA’lar için zorluklar #

Her iki aynı kökenli yaklaşımda ortak olan bazı pratik sorunlar şunlardır:

• Depolamak: Çerezler, yerel depolama ve tüm cihaz yerel depolama biçimleri uygulamalar arasında paylaşılır. Bu nedenle, kullanıcı bir uygulama için yerel verileri silmeye karar verirse, kaynaktaki tüm verileri silecektir; Bunu tek bir uygulama için yapmanın bir yolu yoktur. Chrome ve diğer bazı tarayıcıların, uygulamalardan birini kaldırırken kullanıcılardan aktif olarak yerel verileri silmelerini isteyeceğini ve bunun, kaynaktaki diğer uygulamaların verilerini de etkileyeceğini unutmayın. Diğer bir sorun da, uygulamaların depolama kotalarını paylaşmak zorunda kalacak olmalarıdır; bu da, herhangi birinin çok fazla yer kaplaması durumunda diğerinin olumsuz etkileneceği anlamına gelir.
• İzinler: İzinler, kaynağa bağlıdır. Bu, kullanıcı bir uygulamaya izin verirse, o kaynaktaki tüm uygulamalara aynı anda uygulanacağı anlamına gelir. Bu iyi bir şey gibi görünebilir (birden çok kez izin istemek zorunda değilsiniz), ancak unutmayın: Kullanıcı bir uygulamaya izin verirse, diğerlerinin de bu izni talep etmesini veya bu özelliği kullanmasını engeller.
• Kullanıcı ayarları: Ayarlar ayrıca her kaynak için ayarlanır. Örneğin, iki uygulamanın farklı yazı tipi boyutları varsa ve kullanıcı bunu telafi etmek için bunlardan yalnızca birinde yakınlaştırmayı ayarlamak istiyorsa, ayarı diğer uygulamalara da uygulamadan bunu yapamaz.

Bu zorluklar, bu yaklaşımı teşvik etmeyi zorlaştırıyor. Bununla birlikte, aşağıda açıklandığı gibi ayrı bir kaynak (örn. bir alt alan adı) kullanamıyorsanız, Ayrı kökenleri kullanma bölümünde, sunduğumuz iki aynı kaynak seçeneğinden, örtüşen/iç içe geçmiş yollar yerine örtüşmeyen yolları kullanmanız şiddetle tavsiye edilir.

Bahsedildiği gibi, bu bölümde tartışılan zorluklar aynı kökenli yaklaşımların her ikisinde de ortaktır. Bir sonraki bölümde, örtüşen/iç içe geçmiş yolları kullanmanın neden en az önerilen strateji olduğunun ayrıntılarına ineceğiz.

Çakışan/iç içe geçmiş yollar için ek zorluklar #

Çakışan/iç içe geçmiş yollar yaklaşımıyla ilgili ek sorun (burada dış uygulama ve app/ iç uygulamadır), iç uygulamadaki tüm URL’lerin aslında hem dış uygulamanın hem de iç uygulamanın parçası olarak kabul edileceğidir.

Uygulamada bu, aşağıdaki sorunları sunar:

• Kurulum Promosyonu: Kullanıcı iç uygulamayı ziyaret ederse (örneğin, bir web tarayıcısında), dış uygulama zaten kullanıcının cihazında yüklüyse, tarayıcı yükleme tanıtım afişlerini göstermez ve BeforeInstallPrompt olayı tetiklenmez. Bunun nedeni, tarayıcının mevcut sayfanın zaten kurulu olan bir uygulamaya ait olup olmadığını kontrol edip görmesi ve öyle olduğu sonucuna varmasıdır. Bunun geçici çözümü, iç uygulamayı manuel olarak yüklemek (“Kısayol Oluştur” tarayıcı menü seçeneği aracılığıyla) veya önce iç uygulamayı dış uygulamadan önce yüklemektir.
• Bildiri ve Rozetlendirme API’sı: Dış uygulama yüklüyse ancak iç uygulama yüklü değilse, iç uygulamadan gelen bildirimler ve rozetler yanlışlıkla dış uygulamaya (yüklü bir uygulamanın en yakın kapsama alanıdır) atfedilir. Bu özellik, kullanıcının cihazında her iki uygulamanın da yüklü olması durumunda düzgün çalışır.
• Bağlantı Yakalama: Dış uygulama, iç uygulamaya ait URL’leri yakalayabilir. Bu, özellikle dış uygulama yüklüyse ancak iç uygulama yüklü değilse olasıdır. Benzer şekilde, dış uygulamanın kapsamında oldukları düşünüldüğünden, iç uygulamaya bağlanan dış uygulama içindeki bağlantılar, yakalamayı iç uygulamaya bağlamaz. Ayrıca, ChromeOS ve Android’de, bu uygulamalar Play Store’a eklenirse (olduğu gibi Güvenilir Web Etkinlikleri), dış uygulama tüm bağlantıları yakalayacaktır. İç uygulama yüklenmiş olsa bile işletim sistemi, kullanıcıya bunları dış uygulamada açma seçeneği sunacaktır.

Çözüm #

Bu makalede, geliştiricilerin birbiriyle ilişkili birden çok Progresif Web Uygulaması oluşturabilecekleri farklı yolları inceledik. ihtisas.

Özetle, bağımsız PWA’ları barındırmak için farklı bir kaynak kullanmanızı (örn. alt alan adları kullanarak) şiddetle tavsiye ederiz. Bunları aynı kaynakta barındırmak, tarayıcının bunları tamamen farklı uygulamalar olarak kabul etmeyeceği için birçok zorluk sunar.

• Ayrı kökenler: Tavsiye edilen
• Aynı kaynak, çakışmayan yollar: Tavsiye edilmez
• Aynı kaynak, örtüşen/iç içe geçmiş yollar: Kesinlikle tavsiye edilmez

Farklı orijinler kullanmak mümkün değilse, örtüşmeyen yollar kullanarak (örn. app1/ Ve app2/ gibi örtüşen veya iç içe geçmiş yolların kullanılması şiddetle tavsiye edilir. (dış uygulama için) ve app/ (iç uygulama için).

Ek kaynaklar #

Teknik incelemeleri ve önerileri için çok teşekkürler: Joe Medley, Dominick Ng, Alan Cutter, Daniel Murphy, Penny McLachlan, Thomas Steiner ve Darwin Huang

fotoğrafı çeken Tim Mossholder Açık Unsplash