Çok kaynaklı sitelerdeki progresif web uygulamaları

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

Demián Renzulli

Arka plan

Geçmişte, çok kaynaklı mimarileri kullanmanın bazı avantajları vardı ancak Progresif Web Uygulamaları için bu yaklaşım birçok zorluğu da beraberinde getiriyor. Özellikle aynı kaynak politikası, hizmet çalışanları ve önbellekler ile izinler gibi öğelerin paylaşımına ve birden çok kaynakta bağımsız bir deneyim oluşturmaya yönelik kısıtlamalar uygular. Bu makalede, birden çok kaynağın iyi ve kötü kullanımları, ayrıca çok kaynaklı sitelerde Progresif Web Uygulamaları oluşturmayla ilgili zorluklar ve çözümler açıklanmaktadır.

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

Sitelerin çok kaynaklı bir mimari kullanmasının, çoğunlukla bağımsız bir web uygulamaları kümesi sağlamakla veya birbirinden tamamen yalıtılmış deneyimler oluşturmakla ilgili birkaç geçerli nedeni vardır. Kaçınılması gereken kullanımlar da vardır.

İyi

Öncelikle yararlı nedenlere göz atalım:

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

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

Kötü

Bunların hiçbirini yapmıyorsanız, çok kaynaklı bir mimari kullanmak büyük olasılıkla Progresif Web Uygulamaları oluştururken bir 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. Buna örnek olarak, sitenin birleştirilmiş bir deneyimin parçası olması gereken bölümlerini rastgele ayırmak için alt alan adları kullanılabilir.

Ö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 sayfanın https://www.example.com adresinde olması, spor bölümünün https://sports.example.com, siyasetin https://politics.example.com vb. adresinde yayınlanması normaldir. 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 değer kullanılır.

• Kullanıcı İşlemleri: Alt alan adlarındaki giriş sayfaları veya satın alma işlemleri gibi sitenin daha küçük bölümlerinin (ör. giriş sayfaları veya satın alma akışları) ayrılması önerilmeyen başka bir yaklaşımdır. Örneğin, https://login.example.com ve https://checkout.example.com kullanarak.

Not: Sıfırdan bir site oluştururken sitenin alt alan adlarına bölünmemesi önerilir. Mevcut siteler için tek bir kaynağa geçiş yapmak en iyi yaklaşımdır.

Tek bir kaynağa taşımanın mümkün olmadığı durumlarda, aşağıda zorlukların bir listesi ve (mümkünse) Progresif Web Uygulamaları oluştururken göz önünde bulundurulabilecek geçici çözümler bulunmaktadır.

Farklı kaynaklardaki PWA'lar (Progresif Web Uygulaması) için Zorluklar ve Çözümler

Birden fazla kaynak üzerinde web sitesi oluştururken, çeşitli kısıtlamalara neden olan aynı kaynak politikası nedeniyle birleşik bir PWA deneyimi sağlamak zordur. Bunları birer birer inceleyelim.

Hizmet çalışanları

Service Worker komut dosyası URL'sinin kaynağı, register() işlevini çağıran sayfanın kaynağıyla aynı olmalıdır. Diğer bir deyişle, örneğin https://www.example.com adresindeki bir sayfa, https://section.example.com adresindeki bir Service Worker URL'si ile register() çağıramaz.

Dikkat edilmesi gereken bir diğer nokta da Service Worker'ı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 alanında barındırılıyorsa yalnızca bu kaynaktaki URL'leri (kapsam parametresinde tanımlanan yola göre) kontrol edebilir, ancak https://section.example.com gibi diğer alt alan adlarındaki herhangi bir sayfayı kontrol edemez.

Bu durumda tek geçici çözüm, birden çok Service Worker kullanmaktır (kaynak başına bir adet).

Dikkat: Kayıt ve birden fazla etkin Service Worker'a sahip olmak ek kaynaklar (bellek, CPU vs.) tüketir. Bu nedenle, bir kullanıcının sitede gezinmek için kaç etkin Service çalışana ihtiyaç duyabileceğine siz karar verin.

Önbelleğe alma

Önbellek nesnesi, indexDB ve localStorage da tek bir kaynakla sınırlandırılmıştır. Bu, https://www.example.com öğesine ait önbelleklere erişilemeyeceği anlamına gelir (örneğin, https://www.section.example.com).

Aşağıdaki gibi durumlarda önbellekleri doğru bir şekilde yönetmek için yapabileceğiniz bazı işlemler şunlardır:

• Tarayıcı önbelleğine alma özelliğinden yararlanın: Her zaman geleneksel tarayıcı önbelleğine almayla ilgili en iyi uygulamalardan yararlanmanız önerilir. Bu teknik, önbelleğe alınan kaynakları kaynaklar genelinde yeniden kullanma avantajı sağlar. Bu işlem, hizmet çalışanının önbelleğiyle yapılamaz. HTTP Önbelleğini Service Worker'larla kullanma ile ilgili en iyi uygulamalar için bu yayına göz atabilirsiniz.

• Hizmet çalışanı kurulumunu hafif tutun: Birden fazla hizmet çalışanının bakımını yapıyorsanız kullanıcıların yeni bir kaynağa her gittiğinde yüksek bir kurulum maliyeti ödemek zorunda kalmayın. Yani yalnızca kesinlikle gerekli olan kaynakları önbelleğe alın.

Service Worker etkin olup çalışmaya başladıktan sonra aynı kaynak politikası, inside hizmet çalışanlarına yapılan kaynaklar arası istekleri de kısıtlar. Neyse ki bunun önerilen bir geçici çözümü vardır. Bu işlem CORS'yi kullanmaktır (burada açıklandığı gibi). Service Worker'ın içinden kaynaklar getirilirken bozulmaz modunun kullanılması önerilmez.

İzinler

İzinler, kaynaklar için de kapsama dahil edilir. Yani, kullanıcı https://section.example.com kaynağına belirli bir izin verdiyse kaynak, 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 bir alt alan adı için izin istemektir. Web push gibi durumlarda, iznin başka bir alt alan adında kullanıcı tarafından kabul edilip edilmediğini takip etmek için bir çerez kullanabilirsiniz. Böylece tekrar izin istenmez.

Döşeme

PWA yüklemek için her kaynağın kendine kıyasla bir start_url içeren kendi manifesti olmalıdır. Yani, yükleme istemini belirli bir kaynakta (ör.https://section.example.com) alan kullanıcı, PWA'yı farklı bir kaynakta (ör.https://www.example.com) start_url ile yükleyemez. Diğer bir deyişle, yükleme istemini bir alt alan adında alan kullanıcılar uygulamanın ana URL'sine değil, yalnızca alt sayfalar için PWA'ları yükleyebilir.

Her alt alan adının yükleme ölçütlerini karşılaması ve kullanıcıdan PWA'yı yüklemesini istemesi durumunda, aynı kullanıcının sitede gezinirken birden fazla yükleme istemi alması da sorunu vardır.

Bu sorunu azaltmak için istemin yalnızca ana kaynakta gösterildiğinden emin olabilirsiniz. Bir kullanıcı, yükleme ölçütlerini geçen bir alt alan adını ziyaret ettiğinde:

1. beforeinstallprompt etkinliğini dinle.
2. event.preventDefault() numaralı telefonu arayarak istemin görünmesini engelleyin.

Bu şekilde, istemin sitenin istenmeyen bölümlerinde gösterilmemesini sağlarken, ö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 manifesti tarafından belirlenen kapsamın dışına çıktığında tarayıcı farklı davranır. Davranış, her tarayıcı sürümüne ve satıcıya bağlıdır. Örneğin, kullanıcı bağımsız modda kapsamın dışına çıktığında, en son Chrome sürümlerinde bir Chrome Özel Sekmesi açılır.

Çoğu durumda, bunun için bir çözüm yoktur ancak deneyimin alt alan adlarında barındırılan küçük kısımları (örneğin, giriş iş akışları) için geçici bir çözüm uygulanabilir:

1. Yeni URL (https://login.example.com) tam ekran iframe içinde açılabilir.
2. Görev iframe içinde tamamlandıktan sonra (örneğin, giriş işlemi), iframe'den elde edilen bilgilerin tekrar üst sayfaya aktarılması için postMessage() kullanılabilir.
3. Son adım olarak, ileti ana sayfa tarafından alındıktan sonra işleyicilerin kaydı iptal edilebilir ve iframe son olarak DOM'dan kaldırılabilir.

Dikkat: Önceki teknik, kullanıcının bir alt alanda bir işlem gerçekleştirip ana kaynağa geri dönebileceği (giriş akışında olduğu gibi) sitenin küçük bir bölümündeki olası kullanıcı arayüzü değişikliğini azaltmaya yardımcı olabilir, ancak alt alanlarda barındırılan birçok sayfa da dahil olmak üzere yolların tamamında (site bölümlerinin tamamı gibi) uygulanması etkili bir teknik olmaz.

Not: Güvenilir Web Etkinlikleri bağlamında, bu sorundan kaçınmanın bir yolu vardır. Bunun için dijital öğe bağlantılarını kullanarak tüm kaynakları doğrulayabilirsiniz.

Sonuç

Aynı kaynak politikası, tutarlı bir PWA deneyimi elde etmek isteyen birden çok kaynak temel alınarak oluşturulmuş sitelere birçok kısıtlama getirir. Bu nedenle, kullanıcılara en iyi deneyimi sunmak için siteleri farklı kaynaklara ayırmamanızı önemle tavsiye ederiz.

Zaten bu şekilde oluşturulmuş mevcut siteler için çok kaynaklı PWA'ların doğru çalışmasını sağlamak zor olabilir, ancak bazı olası çözümleri araştırdık. Her birinin kendine göre bazı ödünleri olabilir. Bu nedenle, web sitenizde hangi yaklaşımı uygulayacağınıza karar verirken sağduyunuzu kullanın.

Uzun vadeli bir strateji veya sitenin yeniden tasarımını değerlendirirken, çok kaynaklı mimariyi korumak için önemli bir neden olmadığı sürece tek bir kaynağa taşımayı düşünün.

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