Çok kaynaklı sitelerdeki progresif web uygulamaları

Çok kaynaklı sitelerde progresif web uygulamaları oluşturmayla ilgili zorluklar ve geçici çözümler.

Demián Renzulli

Yayınlanma tarihi: 19 Ağustos 2019

Geçmişte, çok kaynaklı mimarileri kullanmanın bazı avantajları vardı. Progresif web uygulamaları için bu yaklaşım birçok zorluk yaratır. Özellikle aynı kaynak politikası, hizmet çalışanları ve önbellekler gibi öğelerin paylaşılması, izinler ve birden fazla kaynakta bağımsız bir deneyim elde edilmesi konusunda kısıtlamalar getirir.

Birden fazla kaynak kullanmanın iyi ve kötü yönlerini keşfedin. Ayrıca, çok kaynaklı sitelerde progresif web uygulamaları oluşturmayla ilgili zorlukları ve geçici çözümleri açıklayın.

Birden fazla kaynağın iyi ve kötü kullanımları

Sitelerin çok kaynaklı mimari kullanmasının birkaç geçerli nedeni vardır. Bunlar çoğunlukla bağımsız bir web uygulamaları grubu sağlamak veya birbirinden tamamen izole edilmiş deneyimler oluşturmakla ilgilidir. Kaçınılması gereken kullanımlar da vardır.

İyi

Öncelikle faydalı nedenlere göz atın:

• Yerelleştirme / Dil: Farklı ülkelerde yayınlanacak siteleri ayırmak için ülke kodu üst düzey alanı (ör. https://www.google.com.ar) kullanma veya farklı konumlara yönelik siteleri bölmek için alt alanlar kullanma (ör. https://newyork.craigslist.org) veya belirli bir dilde içerik sunmak için (ör. https://en.wikipedia.org).

• Bağımsız web uygulamaları: Amacı ana kaynak sitesinden önemli ölçüde farklı olan deneyimler sunmak için farklı alt alan adları kullanma. Örneğin, bir haber sitesinde bulmaca web uygulaması, ana web sitesiyle herhangi bir kaynak veya işlev paylaşmak zorunda kalmadan https://crosswords.example.com üzerinden kasıtlı olarak sunulabilir ve bağımsız bir PWA olarak yüklenip kullanılabilir.

Kötü

Bu işlemlerden hiçbirini yapmıyorsanız Progresif Web Uygulamaları oluştururken çok kaynaklı mimari kullanmak muhtemelen dezavantajlı olacaktır.

Buna rağmen birçok site, belirli bir neden olmaksızın veya "eski" nedenlerden dolayı bu şekilde yapılandırılmaya devam ediyor. Bir örnek, birleşik bir deneyimin parçası olması gereken bir sitenin bölümlerini rastgele ayırmak için alt alan adlarının kullanılmasıdır.

Örneğin, aşağıdaki kalıpların kullanılması kesinlikle önerilmez:

• Site bölümleri: Bir sitenin farklı bölümlerini alt alan adlarına ayırma. Haber sitelerinde ana sayfa genellikle https://www.example.com, spor bölümü https://sports.example.com, siyaset bölümü ise https://politics.example.com adresinde bulunur. E-ticaret sitesi söz konusu olduğunda ürün kategorileri için https://category.example.com, ürün sayfaları için https://product.example.com gibi bir ayırıcı kullanın.

• Kullanıcı Akışı: Sitenin farklı küçük bölümlerini (ör. alt alan adlarındaki giriş veya satın alma akışlarına yönelik sayfalar) ayırmak da önerilmeyen bir yaklaşımdır. Örneğin, https://login.example.com ve https://checkout.example.com kullanma.

Tek bir kaynağa geçişin mümkün olmadığı durumlarda, progresif web uygulamaları oluştururken dikkate alınabilecek zorlukların ve (mümkün olduğunda) geçici çözümlerin listesini aşağıda bulabilirsiniz.

Farklı kaynaklardaki progresif web uygulamalarıyla ilgili zorluklar ve geçici çözümler

Birden fazla kaynakta web sitesi oluştururken birleşik bir PWA deneyimi sunmak zordur. Bunun temel nedeni, bir dizi kısıtlama getiren aynı kaynak politikasıdır. Bunlara tek tek göz atalım.

Hizmet çalışanları

Service worker komut dosyası URL'sinin kaynağı, register() işlevini çağıran sayfanın kaynağıyla aynı olmalıdır. Örneğin, https://www.example.com adresindeki bir sayfa, https://section.example.com adresindeki bir service worker URL'siyle register() işlevini çağıramaz.

Bir diğer önemli nokta ise hizmet çalışanının yalnızca ait olduğu kaynak ve yol altında barındırılan sayfaları kontrol edebilmesidir. Bu, hizmet çalışanı https://www.example.com konumunda barındırılıyorsa yalnızca bu kaynaktaki URL'leri (kapsam parametresinde tanımlanan yola göre) kontrol edebileceği ancak diğer alt alan adlarındaki sayfaları (ör. https://section.example.com alt alan adındaki sayfalar) kontrol edemeyeceği anlamına gelir.

Bu durumda, tek çözüm birden fazla hizmet çalışanı (kaynak başına bir tane) kullanmaktır.

Önbelleğe alma

Önbellek nesnesi, indexedDB ve localStorage de tek bir kaynakla sınırlıdır. Bu nedenle, https://www.example.com'a ait önbelleklere örneğin https://www.section.example.com üzerinden erişilemez.

Bu gibi senaryolarda önbellekleri düzgün bir şekilde yönetmek için yapabileceklerinizden bazıları şunlardır:

• Tarayıcı önbelleğinden yararlanın: Geleneksel tarayıcı önbelleğiyle ilgili en iyi uygulamaları kullanmanız her zaman önerilir. Bu teknik, kaynaklar arasında önbelleğe alınmış kaynakları yeniden kullanma gibi ek bir avantaj sağlar. Bu, hizmet çalışanının önbelleğiyle yapılamaz. HTTP önbelleğini hizmet çalışanlarıyla kullanmayla ilgili en iyi uygulamalar için bu yayına göz atabilirsiniz.

• Service worker yüklemesini hafif tutun: Birden fazla service worker kullanıyorsanız kullanıcıların yeni bir kaynağa her gittiğinde büyük bir yükleme maliyeti ödemesini önleyin. Başka bir deyişle: Yalnızca kesinlikle gerekli olan kaynakları önbelleğe alın.

İzinler

İzinler kaynaklarla da sınırlandırılır. Bu, bir kullanıcının https://section.example.com kaynağına verdiği bir iznin https://www.example.com gibi diğer kaynaklara aktarılmayacağı anlamına gelir.

İzinleri kaynaklar arasında paylaşmanın bir yolu olmadığından, buradaki tek çözüm belirli bir özelliğin (ör. konum) gerekli olduğu her alt alanda izin istemektir. Web push gibi özellikler için, iznin başka bir alt alanda kullanıcı tarafından kabul edilip edilmediğini izlemek üzere bir çerez tutarak izni tekrar istemekten kaçınabilirsiniz.

Kurulum

PWA yüklemek için her kaynağın, kendisine göre start_url içeren kendi manifest dosyası olmalıdır. Bu durumda, belirli bir kaynakta (ör.https://section.example.com) yükleme istemi alan bir kullanıcı, farklı bir kaynakta (ör.https://www.example.com) start_url ile PWA yükleyemez. Başka bir deyişle, bir alt alan adında yükleme istemi alan kullanıcılar yalnızca alt sayfalar için PWA yükleyebilir, uygulamanın ana URL'si için yükleyemez.

Ayrıca, her alt alan adı yükleme ölçütlerini karşılıyorsa ve kullanıcıya PWA'yı yüklemesi için istem gösteriyorsa aynı kullanıcı siteye göz atarken birden fazla yükleme istemi alabilir.

Bu sorunu azaltmak için istemin yalnızca ana kaynakta gösterildiğinden emin olabilirsiniz. Kullanıcı, yükleme ölçütlerini karşılayan bir alt alanı ziyaret ettiğinde:

1. beforeinstallprompt etkinliğini dinleyin.
2. event.preventDefault() işlevini çağırarak istemlerin görünmesini engelleyin.

Bu sayede, istemin sitenin istenmeyen bölümlerinde gösterilmediğinden emin olursunuz.İstem, örneğin ana kaynakta (ör. ana sayfa) gösterilmeye devam edebilir.

Bağımsız Mod

Bağımsız bir pencerede gezinirken kullanıcı, PWA'nın manifest dosyasında belirlenen kapsamın dışına çıktığında tarayıcı farklı şekilde davranır. Bu davranış, her tarayıcı sürümüne ve tedarikçiye göre değişir. Örneğin, kullanıcı bağımsız modda kapsam dışına çıktığında en son Chrome sürümleri Chrome özel sekmesi açar.

Çoğu durumda bu sorunun çözümü yoktur ancak deneyimin alt alan adlarında barındırılan küçük bölümleri için geçici bir çözüm uygulanabilir (örneğin: oturum açma iş akışları):

1. Yeni URL, https://login.example.com, tam ekran iFrame içinde açılabilir.
2. Görev iFrame içinde tamamlandıktan sonra (ör. oturum açma işlemi), iFrame'den elde edilen bilgileri üst sayfaya geri aktarmak için postMessage() kullanılabilir.
3. Son adım olarak, mesaj ana sayfa tarafından alındıktan sonra dinleyicilerin kaydı silinebilir ve iframe nihayet DOM'dan kaldırılabilir.

Sonuç

Aynı kaynak politikası, tutarlı bir PWA deneyimi elde etmek isteyen birden fazla kaynak üzerine kurulu siteler için birçok kısıtlama getirir. Bu nedenle, kullanıcılara en iyi deneyimi sunmak için siteleri farklı kaynaklara bölmemenizi önemle tavsiye ederiz.

Bu şekilde oluşturulmuş mevcut sitelerde çok kaynaklı PWA'ların doğru şekilde çalışmasını sağlamak zor olabilir ancak bazı olası geçici çözümleri araştırdık. Her birinin dezavantajları olabilir. Bu nedenle, web sitenizde hangi yaklaşımı kullanacağınıza karar verirken dikkatli olun.

Uzun vadeli bir stratejiyi veya siteyi yeniden tasarlamayı değerlendirirken çok kaynaklı mimariyi korumak için önemli bir nedeniniz yoksa tek kaynaklı bir yapıya geçmeyi düşünün.

Teknik incelemeleri ve önerileri için Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle ve Andre Bandarra'ya çok teşekkür ederiz.