Bu sayfa, Cloud Translation API ile çevrilmiştir.

Çok kaynaklı sitelerdeki progresif web uygulamaları

Çok kaynaklı sitelerde Progresif Web Uygulamaları (pwa) oluşturmanın zorlukları ve geçici çözümleri.

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 gibi öğelerin paylaşımı ve birden fazla kaynak genelinde bağımsız bir deneyim elde etme gibi kısıtlamalar uygular. Bu makalede, birden fazla kaynağın iyi ve kötü kullanımları, ayrıca çok kaynaklı sitelerde Progresif Web Uygulamaları oluşturmanın zorlukları ve çözümleri açıklanmaktadır.

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

Sitelerin çok kaynaklı mimariyi kullanmasının, büyük ölçüde bağımsız bir web uygulamaları kümesi sağlamakla veya birbirinden tamamen izole edilmiş deneyimler oluşturmakla alakalı birkaç geçerli nedeni vardır. Kaçınılması gereken kullanımlar da vardır.

İyi

İlk olarak kullanışlı nedenlere göz atalım:

Yerelleştirme / Dil: Farklı ülkelerde hizmet verecek siteleri ayırmak için ülke kodu üst düzey alan kullanma (ör. https://www.google.com.ar) veya farklı konumlara hedeflenen siteleri ayırmak için alt alan adları kullanma (ör. https://newyork.craigslist.org) veya belirli bir dilde (ör. https://en.wikipedia.org) içerik sunmak için.
Bağımsız web uygulamaları: Amacı ana kaynaktaki siteden önemli ölçüde farklı olan deneyimler sağlamak için farklı alt alan adları kullanmak. Örneğin, bir haber sitesinde çapraz kelime olarak kullanılan web uygulaması, herhangi bir kaynak veya işlevi ana web sitesiyle paylaşmaya gerek kalmadan bağımsız bir PWA olarak yüklenerek kullanılabilir.https://crosswords.example.com

Kötü

Bunların hiçbirini yapmıyorsanız çok kaynaklı bir mimari kullanmak, Progresif Web Uygulamaları'nı geliştirirken büyük olasılıkla bir dezavantaj oluşturacaktır.

Buna rağmen, birçok site belirli bir neden ya da "eski" nedenlerle bu şekilde yapılandırılmaya devam etmektedir. Bir sitenin birleştirilmiş deneyimin parçası olması gereken bölümleri rastgele bir şekilde ayırmak için alt alan adları kullanmak buna bir örnek olarak gösterilebilir.

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

Site bölümleri: Bir sitenin farklı bölümlerini alt alan adlarında ayırma. Haber sitelerinde ana sayfanın https://www.example.com, spor bölümünün https://sports.example.com, siyaset ise https://politics.example.com vb. adresinde görülmesi 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 etiketi kullanın.
Kullanıcı Akışı: Önerilmeyen bir diğer yaklaşım, sitenin daha küçük farklı bölümlerini (ör. alt alan adlarındaki giriş veya satın alma akışlarına ait sayfalar) ayırmaktır. Örneğin, https://login.example.com ve https://checkout.example.com kullanılarak.

Tek bir kaynağa taşımanın mümkün olmadığı durumlarda, progresif web uygulamaları oluştururken göz önünde bulundurulabilecek zorlukların ve (mümkün olan durumlarda) geçici çözümlerin bir listesi aşağıda verilmiştir.

Farklı kökenlerdeki PWA'larla İlgili Zorluklar ve Geçici Çözümler

Çeşitli kısıtlamalara tabi olan aynı kaynak politikası nedeniyle, birden fazla kaynakta web sitesi oluştururken birleşik bir PWA deneyimi sunmak zordur. Şimdi tek tek inceleyelim.

Hizmet çalışanları

Service Worker komut dosyası URL'sinin kaynağı, register() çağrısı yapan sayfanın kaynağıyla aynı olmalıdır. Yani, örneğin https://www.example.com üzerindeki bir sayfa, https://section.example.com konumundaki bir hizmet çalışanı URL'si ile register() öğesini ç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 alanlardaki hiçbir sayfayı kontrol edemez.

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

Önbelleğe alma

Önbellek nesnesi, indexDB ve localStorage de tek bir kaynakla sınırlandırıldı. Bu, https://www.example.com ürününe ait önbelleklere, örneğin https://www.section.example.com üzerinden erişilemeyen anlamına gelir.

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ğine alma en iyi uygulamalarını her zaman kullanmanız önerilir. Bu teknik, önbelleğe alınan kaynakların kaynaklar genelinde yeniden kullanılması gibi ek bir avantaj sağlar. Bu işlem, hizmet çalışanının önbelleğiyle yapılamaz. HTTP Önbelleğinin Service Worker'larla nasıl kullanılacağına dair en iyi uygulamalar için bu yayına göz atabilirsiniz.
Service Worker'ın kurulumunu hafifletin: Birden fazla Service Worker ile çalışıyorsanız yeni bir kaynağa giden her kullanıcı için yüksek bir yükleme maliyeti ödemekten kaçının. Başka bir deyişle, yalnızca kesinlikle gerekli olan kaynakları önbelleğe alın.

İzinler

İzinler, kaynakları da kapsar. Bu durumda, kullanıcı https://section.example.com kaynağına belirli bir izin verdiyse kaynak https://www.example.com gibi diğer kaynaklara aktarılmaz.

Kaynaklar arasında izinleri paylaşmanın bir yolu olmadığından buradaki tek çözüm, belirli bir özelliğin gerekli olduğu her alt alan adı için (ör. konum) izin istemektir. Web push gibi işlemlerde, tekrar istekte bulunmamak için iznin başka bir alt alan adında kabul edilip edilmediğini takip edecek bir çerez tutabilirsiniz.

Döşeme

PWA yüklemek için her kaynağın kendisiyle göreli bir start_url içeren kendi manifesti olmalıdır. Yani, belirli bir kaynakta (ör: https://section.example.com) yükleme istemini alan bir kullanıcı, start_url ile PWA'yı farklı bir kaynağa (ör: https://www.example.com) yükleyemez. Diğer bir deyişle, bir alt alan adında yükleme istemini 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 yükleme ölçütlerini karşılıyorsa ve kullanıcıdan PWA'yı yüklemesini isterse 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:

beforeinstallprompt etkinliğini dinle.
event.preventDefault() komutunu çağırarak istemin görünmesini engelleyin.

Bu şekilde, istemin sitenin istenmeyen kısımlarında gösterilmemesini sağlarken, aynı zamanda istemi 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ı tarafından belirlenen kapsamın dışına çıktığında tarayıcı farklı davranır. Bu davranış, her tarayıcı sürümüne ve satıcıya bağlıdır. Örneğin, en son Chrome sürümlerinde, kullanıcı bağımsız modda kapsam dışına çıktığında 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 bölümleri (örneğin, giriş iş akışları) için geçici bir çözüm uygulanabilir:

Yeni URL (https://login.example.com) tam ekran iframe içinde açılabilir.
Görev iframe'in içinde tamamlandıktan sonra (örneğin, giriş işlemi) iframe'den sonuç olarak ortaya çıkan bilgileri üst sayfaya geri iletmek için postMessage() kullanılabilir.
Son adım olarak, mesaj ana sayfa tarafından alındıktan sonra işleyicilerin kaydı iptal edilebilir ve iframe son olarak DOM'den kaldırılır.

Sonuç

Aynı kaynak politikası, tutarlı bir PWA deneyimi elde etmek isteyen birden fazla kaynağı temel alarak oluşturulan sitelere birçok kısıtlama getirir. Bu nedenle, kullanıcılara en iyi deneyimi sağlamak için siteleri farklı kaynaklara ayırmanızı önemle tavsiye ederiz.

Halihazırda bu şekilde oluşturulmuş mevcut siteler söz konusu olduğunda çok kaynaklı PWA'ların doğru şekilde çalışmasını sağlamak zor olabilir ancak bazı olası çözümleri inceledik. Her birinin artıları ve eksileri olabilir. Bu nedenle, web sitenizde hangi yaklaşımı kullanacağınıza karar verirken kendi değerlendirmenizi yapın.

Uzun vadeli bir stratejiyi veya siteyi yeniden tasarlamayı değerlendirirken, çok kaynaklı mimariyi korumak için önemli bir neden olmadığı sürece 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.