Aynı alanda birden fazla progresif web uygulaması oluşturma

Kullanıcının aynı kuruluş veya hizmete ait olduğunu fark etmesini sağlamak için aynı alan adından yararlanarak birden fazla PWA oluşturma

Chase Phillips

Demián Renzulli

Matt Giuca

Çok kaynaklı sitelerde Progresif Web Uygulamaları (pwa) blog yayınında Demian, birden çok kaynak temel alınarak oluşturulmuş sitelerin tümünü kapsayan tek bir Progresif Web Uygulaması oluşturmaya çalışırken karşılaştıkları zorluklardan bahsetti.

Bu tür site mimarisine örnek olarak bir e-ticaret sitesi verilebilir. Burada:

• Ana sayfa şu adrestedir: https://www.example.com.
• Kategori sayfaları https://category.example.com adresinde barındırılır.
• https://product.example.com adresindeki ürün ayrıntıları sayfaları.

Makalede açıklandığı gibi, aynı kaynak politikası çeşitli kısıtlamalar uygulayarak hizmet çalışanlarının, önbelleklerin ve izinlerin kaynaklar arasında paylaşılmasını engeller. Bu nedenle, bu tür yapılandırmalardan kaçınmanızı ve halihazırda bu şekilde oluşturulmuş siteleri olanların, mümkün olduğunda tek kaynaklı site mimarisine geçiş yapmayı düşünmelerini önemle tavsiye ederiz.

Birleştirilmiş Progresive Web Uygulaması oluşturmaya çalışırken aynı sitenin site bölümleri için farklı kaynaklar kullanmaktan kaçının.

Bu yayında ise tam tersi duruma bakacağız: Farklı kaynaklarda tek bir PWA yerine, aynı alan adından yararlanarak birden fazla PWA sağlamak isteyen şirketlerin durumunu analiz edecek ve bu PWA'ların aynı kuruluş veya hizmete ait olduğunu kullanıcılara ileteceğiz.

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

Teknik terimler

• Alan: Alan Adı Sistemi'nde (DNS) tanımlanan herhangi bir etiket dizisi. Örneğin, com ve example.com alan adlarıdır.
• Ana makine adı: En az bir IP adresine çözümlenen bir DNS girişi. Örneğin: www.example.com bir ana makine adı, example.com bir IP adresi varsa bir ana makine adı olabilir. com ise hiçbir zaman IP adresine çözümlenmez ve dolayısıyla hiçbir zaman ana makine adı olamaz.
• Kaynak: Şema, ana makine adı ve (isteğe bağlı olarak) bağlantı noktasının bileşimi. Örneğin, https://www.example.com:443 bir kaynaktır.

Adından da anlaşılacağı gibi, aynı kaynak politikası kaynaklar üzerinde kısıtlamalar getirir. Bu nedenle, makale boyunca bu terimden yararlanacağız. Bununla birlikte, farklı "kaynakları" oluşturmak için kullanılan tekniği açıklamak için zaman zaman "alanlar" veya "alt alan adları"ndan bahsedeceğiz.

Birbiriyle alakalı birden fazla PWA'nın durumu

Bazı durumlarda, bağımsız uygulamalar oluşturmak, ancak yine de bunları aynı kuruluşa veya "markaya" ait olarak tanımlamak isteyebilirsiniz. Aynı alan adını yeniden kullanmak, bu ilişkiyi kurmak için iyi bir yoldur. Örneğin:

• Bir e-ticaret sitesi, satıcıların envanterlerini yönetmelerine olanak tanımak için bağımsız bir deneyim oluşturmak ve aynı zamanda da envanterin, kullanıcıların ürün satın aldıkları ana web sitesine ait olduklarını anlamalarını istiyor.
• Bir spor haber sitesi, kullanıcıların bildirimler aracılığıyla favori yarışmalarıyla ilgili istatistikleri almak ve bunu bir Progresif Web Uygulaması olarak yüklemek, aynı zamanda kullanıcıların bu uygulamayı haber şirketi tarafından oluşturulmuş bir uygulama olarak kabul etmesini sağlamak için büyük bir spor etkinliği için özel bir uygulama oluşturmak istiyor.
• Bir şirket ayrı sohbet, posta ve takvim uygulamaları oluşturmak ve bu uygulamaların şirket adına bağlı bağımsız uygulamalar olarak çalışmasını istiyor.

example.com'un sahibi olan şirket, aralarında ilişki kurmak için aynı alan adını kullanan üç bağımsız uygulama veya PWA sağlamak istiyor.

Ayrı kaynaklar kullanma

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

Hepsinde aynı alan adını kullanmak istiyorsanız bunu alt alan adlarıyla yapabilirsiniz. Örneğin, birden fazla internet uygulaması veya hizmeti sunan bir şirket, https://mail.example.com adresinde posta uygulaması, https://calendar.example.com adresinde ise takvim uygulaması barındırıp ana hizmetini https://www.example.com adresinde sunabilir. Başka bir örnek de, tamamen https://footballcup.example.com için düzenlenen bir futbol şampiyonası gibi önemli spor etkinliklerine adanmış, kullanıcıların ana spor sitesinden bağımsız olarak yükleyip kullanabileceği, https://www.example.com adresinde barındırılan bağımsız bir uygulama oluşturmak isteyen bir spor sitesidir. Bu yaklaşım, müşterilerin şirket markası altında kendi bağımsız uygulamalarını oluşturmalarına olanak tanıyan platformlar için de faydalı olabilir. Örneğin, satıcıların https://merchant1.example.com, https://merchant2.example.com vb. üzerinde kendi PWA'larını oluşturmalarına olanak tanıyan bir uygulama.

Farklı kaynaklar kullanmak, uygulamalar arasında yalıtım sağlar. Böylece her uygulama, aşağıdakiler gibi farklı tarayıcı özelliklerini bağımsız olarak yönetebilir:

• Yüklenebilirlik: Her uygulamanın kendi Manifest dosyası vardır ve kendi yüklenebilir deneyimi sunulur.
• Depolama alanı: Her uygulamanın kendi önbellekleri, yerel depolama alanı ve temelde tüm cihaz yerel depolama biçimleri vardır. Üstelik bunları başkalarıyla paylaşmazlar.
• Service Workers: Her uygulamanın kayıtlı kapsamlar için kendi hizmet çalışanı vardır.
• İzinler: İzinler, kaynaklara göre de kapsama alınır. Bu sayede kullanıcılar tam olarak hangi hizmet için izin verdiklerini bilirler ve bildirimler gibi özellikler her uygulamayla doğru şekilde ilişkilendirilir.

Birden fazla bağımsız PWA kullanıldığında, böyle bir düzeyde yalıtım en çok istenen yöntem olduğundan bu yaklaşımı önemle tavsiye ederiz.

Alt alanlardaki uygulamalar birbirleriyle yerel veri paylaşmak isterse bunu çerezler aracılığıyla yapabilir. Daha ileri düzey senaryolarda ise depolama alanını bir sunucu üzerinden senkronize etmeyi düşünebilirler.

Alt alan kullanarak farklı kaynaklarda farklı PWA'lar oluşturmak iyi bir uygulamadır.

Aynı kaynağı kullanma

İkinci yaklaşım, farklı PWA'ların aynı kaynakta oluşturulmasıdır. Buna aşağıdaki senaryolar dahildir:

Çakışmayan yollar

Aynı kaynakta barındırılan ve örtüşmeyen yollara sahip birden fazla PWA veya kavramsal "web uygulaması". Örneğin:

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

Çakışan/iç içe yerleştirilmiş yollar

Biri kapsamı diğerinin içine yerleştirilmiş, aynı kaynakta birden fazla PWA:

• https://example.com/ ("dış uygulama")
• https://example.com/app/ ("iç uygulama")

Service Worker API'si ve manifest biçimi, yol düzeyinde kapsam kullanarak yukarıdakilerden birini yapmanıza olanak tanır. Bununla birlikte, her iki durumda da aynı kaynağın kullanılması birçok sorun ve sınırlamaya yol açar. Bunların kaynağı, tarayıcının bunları tam olarak farklı "uygulamalar" olarak değerlendirmemesidir. Bu nedenle bu yaklaşım önerilmez.

Aynı kaynak altında iki bağımsız PWA (uygulama1, "uygulama2") sağlamak için yolların (örtüşen veya çakışmayan) kullanılması önerilmez.

Bir sonraki bölümde bu zorlukları daha ayrıntılı bir şekilde analiz edecek ve ayrı kaynaklar kullanmak mümkün değilse neler yapılabileceğini inceleyeceğiz.

Aynı kaynaklı birden fazla PWA (Progresif Web Uygulaması) için zorluklar

Her iki aynı kaynak yaklaşımında sık karşılaşılan bazı pratik sorunlar aşağıda verilmiştir:

• Depolama: Ç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 siler; 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 aktif olarak kullanıcılardan yerel verileri silmelerini isteyeceklerini ve bu durumun kaynaktaki diğer uygulamaların verilerini de etkileyeceğini unutmayın. Diğer bir sorun da uygulamaların depolama alanı kotasını paylaşmak zorunda olmasıdır. Bu da ikisinden biri çok fazla yer kapladığında diğeri olumsuz etkilenir.
• İzinler: İzinler kaynağa bağlıdır. Diğer bir deyişle, kullanıcı bir uygulamaya izin verirse bu izin, söz konusu kaynaktaki tüm uygulamalar için aynı anda geçerli olur. Bu iyi bir şey gibi görünebilir (birkaç kez izin istemenize gerek yoktur) ancak unutmayın: Kullanıcı bir uygulamaya erişimi engellerse diğer kullanıcıların bu izni istemesini veya bu özelliği kullanmasını engeller.
• Kullanıcı ayarları: Ayarlar da kaynak bazında belirlenir. Örneğin, iki uygulamanın yazı tipi boyutları farklıysa ve kullanıcı bunu telafi etmek için yakınlaştırmayı bunlardan yalnızca birinde ayarlamak isterse, bu ayarı diğer uygulamalara da uygulamadan yapamaz.

Bu zorluklar, bu yaklaşımı teşvik etmeyi zorlaştırır. Bununla birlikte, Ayrı kaynaklar kullanma bölümünde açıklandığı gibi ayrı bir kaynak (ör. alt alan) kullanamıyorsanız sunduğumuz iki aynı kaynak seçeneğinde, çakışan/iç içe yerleştirilmiş yolların üzerine binen çakışma olmayan yolları kullanmanız önemle tavsiye edilir.

Daha önce de belirtildiği gibi, bu bölümde tartışılan zorluklar her iki aynı kaynaklı yaklaşım için de ortaktır. Bir sonraki bölümde, çakışan/iç içe geçmiş yolları kullanmanın neden en az önerilen strateji olduğu konusuna daha ayrıntılı bir şekilde değineceğiz.

Çakışan/iç içe yerleştirilmiş yollar için ek zorluklar

Çakışan/iç içe yerleştirilmiş yollar yaklaşımıyla ilgili diğer sorun (https://example.com/ dış uygulama, https://example.com/app/ iç uygulamadır) iç uygulamadaki tüm URL'lerin aslında hem dış uygulamanın hem de iç uygulamanın bir parçası olarak değerlendirilecek olmasıdır.

Pratikte bu, aşağıdaki sorunlara yol açar:

• Yükleme Tanıtımı: Kullanıcı iç uygulamayı ziyaret ederse (örneğin, bir web tarayıcısında), dış uygulama kullanıcının cihazına önceden yüklenmişse tarayıcı, yükleme tanıtım banner'larını göstermez ve BeforeInstallPrompt etkinliği tetiklenmez. Bunun nedeni, tarayıcının geçerli sayfanın önceden yüklü bir uygulamaya ait olup olmadığını kontrol etmesi ve böyle bir uygulamaya ait olduğu sonucuna varmasıdır. Bunun çözümü, iç uygulamayı manuel olarak ("Kısayol Oluştur" tarayıcı menüsü seçeneğiyle) veya önce iç uygulamayı dış uygulamadan önce yüklemektir.
• Bildirim ve Rozet API'si: Dış uygulama yüklüyken iç uygulama yüklü değilse iç uygulamadan gelen bildirimler ve rozetler hatalı bir şekilde dış uygulamayla ilişkilendirilir (yüklenen uygulamanın en yakın kapsamı). Bu özellik her iki uygulamanın da kullanıcının cihazında 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üyken iç uygulama yüklü değilse gerçekleşebilir. Benzer şekilde, dış uygulama içinde bulunan ve iç uygulamaya bağlantı veren bağlantılar, yakalamayı iç uygulamanın kapsamına girmeleri nedeniyle içerideki uygulamaya bağlantı oluşturmaz. Ayrıca ChromeOS ve Android'de bu uygulamalar Play Store'a eklenirse (Güvenilir Web Etkinlikleri olarak) dış uygulama tüm bağlantıları yakalar. Dahili uygulama yüklü olsa bile işletim sistemi kullanıcıya bunları dış uygulamada açma seçeneği sunacaktır.

Sonuç

Bu makalede, geliştiricilerin aynı alanda birbirleriyle ilişkili birden fazla İleri Web Uygulaması oluşturabilecekleri farklı yöntemleri ele aldık.

Özet olarak, bağımsız PWA'ları barındırmak için farklı bir kaynak (ör. alt alan adları kullanarak) kullanmanızı önemle tavsiye ederiz. Bunların aynı kaynakta barındırılması birçok zorluk yaratır. Bunun başlıca nedeni, tarayıcının bunları tam olarak ayrı uygulamalar olarak kabul etmemesidir.

• Ayrı kaynaklar: Önerilir
• Kaynağı aynı, çakışmayan yollar: Önerilmez
• Aynı kaynak, çakışan/iç içe yerleştirilmiş yollar: Kesinlikle önerilmez

Farklı kaynaklar kullanmak mümkün değilse çakışmayan yollar (ör. https://example.com/app1/ ve https://example.com/app2/) kullanarak, https://example.com/ (dış uygulama için) ve https://example.com/app/ (iç uygulama için) gibi çakışan veya iç içe yerleştirilmiş yolların kullanılması kesinlikle önerilir.

Ek kaynaklar

• Çok kaynaklı sitelerde progresif web uygulamaları

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

Fotoğrafçı: Tim Mossholder'ın Unsplash