Ç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ı (PWA) için bu yaklaşım birçok zorluk doğurur. Özellikle aynı kaynak politikası, hizmet çalışanları ve önbellekler gibi öğelerin paylaşılması, izinler ve birden fazla kaynakta bağımsız bir deneyim elde edilmesiyle ilgili kısıtlamalar getirir.

Birden fazla kaynağın iyi ve kötü kullanım şekillerini keşfedin ve çok kaynaklı sitelerde Progresif Web Uygulamaları oluşturmanın zorluklarını ve geçici çözümlerini açıklayın.

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

Sitelerin çok kaynaklı bir mimari kullanmasının birkaç geçerli nedeni vardır. Bunlar genellikle bağımsız bir web uygulaması 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ı kullanma (ör. https://www.google.com.ar) veya farklı konumları hedefleyen siteleri bölmek için alt alan adları kullanma (ör.: https://newyork.craigslist.org) veya belirli bir dilde içerik sunmak (ör. https://en.wikipedia.org) için kullanabilirsiniz.

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

Kötü yanları

Bunlardan hiçbirini yapmıyorsanız çok kaynaklı mimari kullanmak, Progresif Web Uygulamaları oluştururken muhtemelen dezavantaj olacaktır.

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

Örneğin, aşağıdaki kalıplar kesinlikle ö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 adresinde, spor bölümünün https://sports.example.com adresinde, politika bölümünün https://politics.example.com adresinde vb. olması sık görülen bir durumdur. E-ticaret sitelerinde ürün kategorileri için https://category.example.com, ürün sayfaları için https://product.example.com gibi bir yapı kullanabilirsiniz.

• Kullanıcı işlemleri akışı: Önerilmeyen bir diğer yaklaşım da sitenin farklı küçük bölümlerini (ör. alt alan adlarındaki giriş veya satın alma süreçleri için sayfalar) ayırmaktır. Örneğin, https://login.example.com ve https://checkout.example.com kullanma.

Not: Sıfırdan bir site oluştururken siteyi alt alan adlarına bölmekten kaçınmanız önemle tavsiye edilir. Mevcut siteler için tek bir kaynağa geçiş yapmak en iyi yaklaşımdır.

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 bir listesi aşağıda verilmiştir.

Farklı kaynaklardaki PWA'larla ilgili zorluklar ve geçici çözümler

Birden fazla kaynakta web sitesi oluştururken birleşik bir PWA deneyimi sunmak, genellikle çeşitli kısıtlamalar 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 adresinde hizmet çalışanı URL'si olan register() işlevini çağıramayacağı anlamına gelir.

Dikkate alınması gereken bir diğer nokta da hizmet çalışanının yalnızca ait olduğu kaynak ve yol altında barındırılan sayfaları kontrol edebilmesidir. Yani hizmet çalışanı https://www.example.com adresinde barındırılıyorsa yalnızca bu kaynaktaki URL'leri kontrol edebilir (kapsam parametresinde tanımlanan yola göre) ancak diğer alt alan adlarındaki (ör. https://section.example.com) sayfaları kontrol edemez.

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

Dikkat: Birden fazla etkin hizmet çalışanını kaydetmek ve kullanmak ek kaynaklar (bellek, CPU vb.) tüketir. Bu nedenle, bir kullanıcının sitede gezinmek için muhtemelen kaç etkin hizmet çalışanına ihtiyaç duyacağı konusunda en iyi kararı verin.

Önbelleğe alma

Cache nesnesi, indexedDB ve localStorage da tek bir kaynakla sınırlıdır. Bu, https://www.example.com öğesine ait önbelleklere (ör. https://www.section.example.com) erişilemeyeceği anlamına gelir.

Bu gibi senaryolarda önbellekleri doğru ş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ı kullanmanız her zaman önerilir. Bu teknik, önbelleğe alınmış kaynakların kaynaklar arasında yeniden kullanılabilmesi gibi ek bir avantaj sağlar. Bu, hizmet çalışanının önbelleğiyle yapılamaz. Hizmet çalışanlarıyla HTTP önbelleğini kullanma ile ilgili en iyi uygulamalar için bu yayına göz atabilirsiniz.

• Hizmet çalışanı yüklemesini basit tutun: Birden fazla hizmet çalışanı 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ı önden belleğe alın.

Hizmet çalışanı etkin ve çalışır durumdayken aynı kaynak politikası, hizmet çalışanlarının içinde yapılan çapraz kaynak isteklerini de kısıtlar. Neyse ki bu sorun için önerilen bir geçici çözüm var: CORS kullanmak (burada açıklandığı gibi). Hizmet çalışanının içindeki kaynakları getirirken no-cors modunun kullanılması önerilmez.

İzinler

İzinler, kaynaklara göre de kapsamlandırılır. Yani bir kullanıcı, https://section.example.com kaynağına belirli bir izin verdiyse bu izin https://www.example.com gibi diğer kaynaklara aktarılmaz.

İ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 özellikler için, iznin başka bir alt alan adında kullanıcı tarafından kabul edilip edilmediğini izlemek üzere bir çerez kullanabilirsiniz. Böylece izni tekrar istemeniz gerekmez.

Kurulum

PWA yüklemek için her kaynağın, kendisiyle alakalı bir start_url içeren kendi manifesti olmalıdır. 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 içeren PWA'yı yükleyemeyeceği anlamına gelir. Diğer 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ı sitede gezinirken 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 adını ziyaret ettiğinde:

1. beforeinstallprompt etkinliğini dinleyin.
2. event.preventDefault() yöntemini çağırarak istemin görünmesini engelleme

Bu sayede, istemin sitenin istenmeyen bölümlerinde gösterilmemesini sağlarken ana kaynakta (ör. ana sayfa) göstermeye devam edebilirsiniz.

Bağımsız mod

Bağımsız bir pencerede gezinirken kullanıcı, PWA'nın manifesti tarafından belirlenen kapsamın dışına çıktığında tarayıcı farklı davranır. Davranış, her tarayıcı sürümüne ve tedarikçiye göre değişir. Örneğin, en son Chrome sürümleri, kullanıcı bağımsız modda kapsam 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 iFrame'de açılabilir.
2. Görev iFrame içinde tamamlandıktan sonra (örneğin, giriş işlemi), iFrame'den elde edilen bilgileri üst sayfaya geri göndermek 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.

Dikkat: Önceki teknik, kullanıcının bir alt alan adında işlem yapıp ana kaynağa dönebileceği (giriş akışında olduğu gibi) sitenin küçük bir bölümünde olası kullanıcı arayüzü değişikliğini azaltmaya yardımcı olabilir ancak alt alan adlarında barındırılan birçok sayfa (tüm site bölümleri gibi) dahil olmak üzere tüm yollar için uygulanacak etkili bir teknik değildir.

Not: Güvenilir Web Etkinlikleri bağlamında, Digital Asset Links kullanarak tüm kaynakları doğrulayarak bu sorunu önlemenin önerilen bir yolu vardır.

Sonuç

Aynı kaynak politikası, tutarlı bir PWA deneyimi sunmak isteyen birden fazla kaynak üzerine oluşturulmuş 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ümler bulduk. Her birinin avantajları ve 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 neden yoksa tek bir kaynağa 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.