Çok kaynaklı sitelerdeki progresif web uygulamaları

Çok kaynaklı sitelerde Progressive Web Uygulamaları oluşturmayla ilgili zorluklar ve geçici çözümler.

Demián Renzulli

Arka plan

Geçmişte çok kaynaklı mimarilerin kullanılmasının bazı avantajları vardı ancak bu yaklaşım, Progresif Web Uygulamaları için birçok zorluk sunuyor. Özellikle aynı kaynak politikası, hizmet çalışanları ve önbellekler, izinler gibi öğelerin paylaşılması ve birden fazla kaynakta bağımsız bir deneyim elde edilmesi için kısıtlamalar getirir. Bu makalede, birden fazla kaynağın avantajları ve dezavantajları açıklanmakta, ayrıca birden fazla kaynağın bulunduğu sitelerde Progressive Web Uygulamaları oluşturmayla ilgili zorluklar ve geçici çözümler ele alınmaktadır.

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

Sitelerin çok kaynaklı bir mimari kullanmasının birkaç geçerli nedeni vardır. Bu nedenlerin çoğu, bağımsız bir web uygulaması grubu sağlama veya birbirinden tamamen izole edilmiş deneyimler oluşturma ile ilgilidir. Ayrıca, kaçınılması gereken kullanımlar da vardır.

İyi

Öncelikle, faydalı olan nedenleri inceleyelim:

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

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

Kötü

Bu işlemlerin hiçbirini yapmıyorsanız çok kaynaklı mimari kullanmak, PWA'lar geliştirirken dezavantaj olabilir.

Buna rağmen birçok site, belirli bir nedenden veya "eski" nedenlerden dolayı bu şekilde yapılandırılmaya devam etmektedir. Örneğin, birleştirilmiş bir deneyimin parçası olması gereken site bölümlerini keyfi olarak ayırmak için alt alan adları kullanmak.

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

• Site bölümleri: Bir sitenin farklı bölümlerini alt alan adlarına ayırma. Haber sitelerinde ana sayfanın https://www.example.com, spor bölümünün https://sports.example.com, siyaset bölümünün https://politics.example.com adresinde yer alması yaygın bir durumdur. 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 şey kullanabilirsiniz.

• Kullanıcı Akışları: Sitenin farklı ve daha küçük bölümlerini (ör. alt alan adlarındaki giriş veya satın alma akışları için sayfalar) ayırmak da önerilmez. Örneğin, https://login.example.com ve https://checkout.example.com kullanılmaktadır.

Tek bir kaynağa geçişin mümkün olmadığı durumlarda, aşağıdakiler progresif web uygulamaları oluştururken karşılaşılabilecek zorlukların ve (mümkün olduğunda) geçici çözümlerin bir listesidir.

Farklı kaynaklardaki PWA'lar için zorluklar ve geçici çözümler

Birden fazla kaynakta bir web sitesi oluştururken birleşik bir PWA deneyimi sunmak, çoğunlukla bir dizi kısıtlama getiren aynı kaynak politikası nedeniyle zordur. Bunları tek tek inceleyelim.

Hizmet çalışanları

Hizmet çalışanı komut dosyası URL'sinin kaynağı, register() işlevini çağıran sayfanın kaynağıyla aynı olmalıdır. Bu, örneğin https://www.example.com adresindeki bir sayfanın https://section.example.com adresindeki bir hizmet çalışanı URL'siyle register()'ı çağıramaması anlamına gelir.

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

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

Önbelleğe alma

Önbellek nesnesi, indexedDB ve localStorage da tek bir kaynakla sınırlıdır. Bu, https://www.example.com'e ait önbelleklere örneğin https://www.section.example.com adresinden erişilemeyeceği anlamına gelir.

Bu gibi senaryolarda önbellekleri düzgün şekilde yönetmek için yapabileceğiniz bazı işlemler şunlardır:

• Tarayıcı önbelleğe alma özelliğinden yararlanın: Geleneksel tarayıcı önbelleğe alma en iyi uygulamalarını kullanmak her zaman önerilir. Bu teknik, önbelleğe alınan kaynakları farklı kaynaklarda yeniden kullanma avantajı sağlar. Bu işlem, hizmet çalışanının önbelleğiyle yapılamaz. HTTP önbelleğini hizmet işçileriyle kullanmayla ilgili en iyi uygulamalar için bu yayına göz atabilirsiniz.

• Hizmet çalışanı kurulumunu hafif tutun: Birden fazla hizmet çalışanı kullanıyorsanız kullanıcıların yeni bir kaynağa her gittiklerinde büyük bir kurulum maliyeti ödemesini önleyin. Diğer bir deyişle, yalnızca kesinlikle gerekli olan kaynakları önbelleğe alın.

İzinler

İzinler, kaynaklara göre de kapsamlandırılır. Bu, bir kullanıcı https://section.example.com kaynağına belirli bir izin verdiyse bu izin 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 alan adında izin istemektir. Web push gibi durumlarda, iznin başka bir alt alan adında kullanıcı tarafından kabul edilip edilmediğini izlemek için bir çerez tutarak izni tekrar istemekten kaçınabilirsiniz.

Kurulum

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

Ayrıca, her alt alan adı yükleme ölçütlerini karşılıyorsa ve kullanıcıdan PWA'yı yüklemesini istiyorsa aynı kullanıcının sitede gezinirken birden fazla yükleme istemi alabileceği de bir sorundur.

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 adını ziyaret ettiğinde:

1. beforeinstallprompt etkinliğini dinleyin.
2. event.preventDefault()'yi arayarak istemin görünmesini engelleyin.

Bu sayede, istemin sitenin istenmeyen bölümlerinde gösterilmediğinden emin olurken, örneğin ana kaynakta (ör. Ana Sayfa) göstermeye devam edebilirsiniz.

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ı davranır. Davranış, her tarayıcı sürümüne ve tedarikçiye bağlıdır. Örneğin, en son Chrome sürümleri, kullanıcı bağımsız modda kapsamın dışına çıktığında bir 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 (ör. giriş iş akışları) için geçici bir çözüm uygulanabilir:

1. Yeni URL (https://login.example.com) tam ekran bir iFrame içinde açılabilir.
2. Görev iFrame içinde tamamlandıktan sonra (ör. giriş işlemi), iFrame'den elde edilen tüm bilgileri üst sayfaya 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 DOM'den kaldırılabilir.

Sonuç

Aynı kaynak politikası, tutarlı bir PWA deneyimi elde etmek isteyen ve birden fazla kaynak üzerine inşa edilmiş 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 düzgün çalışmasını sağlamak zor olabilir ancak bazı olası geçici çözümler bulduk. Her birinin avantajları ve dezavantajları olabilir. Bu nedenle, web sitenizde hangi yaklaşımı kullanacağınıza karar verirken dikkatli olun.

Çok kaynaklı mimariyi kullanmaya devam etmek için önemli bir nedeniniz yoksa uzun vadeli bir stratejiyi veya siteyi yeniden tasarlamayı değerlendirirken tek bir kaynağa geçiş yapmayı düşünün.

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