Çok kaynaklı sitelerde aşamalı Web Uygulamaları

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

Arkaplan

Geçmişte, çok kaynaklı mimarileri kullanmanın bazı avantajları vardı, ancak Progressive Web Uygulamaları için bu yaklaşım birçok zorluğu beraberinde getirdi. Özellikle, aynı köken politikası , servis çalışanları ve önbellek, izinler gibi şeyleri paylaşmak ve birden fazla kaynaktan bağımsız bir deneyim kazanmak için kısıtlamalar getirir. Bu makalede, çoklu kaynakların iyi ve kötü kullanımları açıklanacak ve çok kaynaklı sitelerde Progressive Web Uygulamaları oluşturmak için zorluklar ve geçici çözümler açıklanacaktır.

Birden kökenleri İyi ve kötü kullanımları

Sitelerin, çoğunlukla bağımsız bir web uygulaması kümesi sağlamak veya birbirlerinden tamamen izole edilmiş deneyimler oluşturmakla ilgili çok kaynaklı bir mimari kullanmaları için birkaç meşru sebep vardır. Kaçınılması gereken kullanımlar da vardır.

Önce yararlı sebeplere bakalım:

Yerelleştirme / Dil: Bir ülke kodu üst düzey etki alanı kullanmak , farklı ülkelerde hizmet verilecek siteleri ayırmak için (örn. http://www.google.com.ar) Veya farklı bölgelere hedeflenen siteleri bölmek için alt etki alanları kullanmak (örneğin 🙂 http://newyork.craigslist.org veya belirli bir dil için içerik sunmak ( örneğin http://en.wikipedia.org).

Cihaz / Platform: Bir web sitesinin farklı sürümlerini farklı cihazlara sunmak için farklı alt alanlar kullanın. m.Veya mobile.desen adaptif sitelerde masaüstünden mobil ayırmak için yaygın bir yoludur. Örneğin: bir site masaüstü sürümünü adresinde http://www.example.comve mobil sürümünü adresinde tutabilir http://m.example.com.

Bağımsız webapps: Amacı ana sitedeki siteden oldukça farklı olan deneyimler sağlamak için farklı alt alanlar kullanmak. Örneğin, bir haber sitesinde, webapp bulmacaları kasıtlı http://crosswords.example.comolarak kullanılabilir ve herhangi bir kaynak veya işlevselliği ana web sitesi ile paylaşmak zorunda kalmadan bağımsız bir PWA olarak kurulabilir ve kullanılabilir.

Zararlı sebepler:

Bunlardan hiçbirini yapmıyorsanız, Progressive Web Apps’i oluştururken çok kaynaklı bir mimariyi kullanmanın dezavantajı olması muhtemeldir.

Buna rağmen, birçok site belirli bir nedenden dolayı veya ‘eski’ nedenlerden ötürü bu şekilde yapılandırılmaya devam etmektedir. Bir örnek, bir sitenin birleşik bir deneyimin parçası olması gereken bölümlerini keyfi olarak ayırmak için alt alanları kullanıyor.

Örneğin, aşağıdaki desenler kesinlikle önerilmemektedir:

Site bölümleri: Bir sitenin farklı bölümlerini alt alan adlarında ayırma. Haber sitelerinde, giriş sayfasını görmek nadir değildir: http://www.example.comspor bölümünde yaşarken http://sports.example.com, politika http://politics.example.comve diğerleri. Bir e-ticaret sitesi söz konusu olduğunda, http://category.example.comürün kategorileri, http://product.example.comürün sayfaları vb.

Kullanıcı Akışı: Giriş yapılmayan sayfalar veya alt alan adlarında satın alma akışları gibi, sitenin farklı küçük bölümlerini ayırmak için tavsiye edilmeyen bir yaklaşım. Örneğin http://login.example.com, ve kullanarak http://checkout.example.com.

Bir siteyi sıfırdan oluştururken, alt alanlara bölmekten kaçınmanız önerilir. Mevcut siteler için tek bir kökene geçiş en iyi yaklaşımdır.

Tek bir köye göç etmenin mümkün olmadığı durumlar için, aşağıdakiler İlerici Web Uygulamaları oluştururken göz önüne alınabilecek zorlukların ve (mümkünse) geçici çözümlerin listesidir.

Farklı kökenlerdeki PWA’lar için Zorluklar ve Çözümler

Birden fazla kaynaktan bir web sitesi oluştururken, birleşik bir PWA deneyimi sağlamak, çoğunlukla aynı kısıtlamalara neden olan aynı köken politikası nedeniyle zordur . Onlara birer birer bakalım.

Servis çalışanları

Servis çalışanı betiği URL’sinin kökeni, sayfa çağıran register () öğesinin kökeni ile aynı olmalıdır . Bu, örneğin, bir sayfa olarak, yani http://www.example.comçağrı yapamazsınız register()bir hizmet işçisi url ile http://section.example.com.

Diğer bir husus, bir servis çalışanının yalnızca ait olduğu kaynak ve yol altında barındırılan sayfaları kontrol edebilmesidir. Bunun anlamı, hizmet çalışanı barındırılıyorsa, http://www.example.comyalnızca o kökene ait URL’leri ( kapsam parametresinde tanımlanan yola göre ) kontrol edebilir, ancak örneğin, bu siteler gibi diğer alt alanlardaki herhangi bir sayfayı kontrol etmeyecektir http://section.example.com.

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

Dikkat: Birden fazla aktif servis çalışanını kaydettirmek ve bulundurmak, ek kaynaklar (bellek, CPU vb.) Tüketir; bu nedenle, bir kullanıcının sitede gezinmek için kaç tane aktif servis çalışanı olması gerektiği konusunda en iyi kararınızı verin.

Önbelleğe alma

#IndexedDB ve localStorage adlı Cache nesnesi de tek bir orijinli olarak sınırlandırılmıştır. Bu aittir önbelleklerini erişmek mümkün değil demektir http://www.example.com, örneğin gelen: http://www.section.example.com.

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

Tarayıcı önbelleğini kullanma özelliğinden yararlanın: Her zaman en iyi uygulamaları geleneksel tarayıcı önbelleğe alma özelliğini kullanarak önerilir. Bu teknik, servis çalışanının önbelleğiyle yapılamayan, kaynaklar arasında önbellek kaynaklarının yeniden kullanılmasının ilave faydasını sağlar. HTTP Önbelleğini servis çalışanlarıyla birlikte kullanma konusundaki en iyi uygulamalar için bu gönderiye göz atabilirsiniz .

Servis çalışanı kurulumunu hafif tutun: Birden fazla servis çalışanı tutuyorsanız, her yeni menşe için her seferinde kullanıcıların büyük bir kurulum maliyeti ödemesini önleyin. Başka bir deyişle: yalnızca kesinlikle gerekli olan önbellek kaynaklarını kullanın.

Sorunlar!

Servis çalışanı aktif ve çalışır durumdayken, aynı orijinli politika, servis çalışanları içinde yapılan çapraz orijinallik taleplerini de kısıtlar . Neyse ki bu, CORS’u kullanmak için önerilen ( burada açıklandığı gibi ) geçici bir çözümü vardır . Servis çalışanının içine kaynakları alırken no-cor modunu kullanmanız önerilmez.

İzinler

İzinler de kökenlerle ilgilidir. Bu, bir kullanıcının menşei için belirli bir izin vermesi durumunda http://maps.google.com, bunun gibi diğer menşelere devredilmeyeceği anlamına gelir http://www.google.com.

Kaynaklar arasında izinleri paylaşmanın bir yolu olmadığından, buradaki tek çözüm, belirli bir özelliğin gerekli olduğu her bir alt etki alanı için izin istektir (örn. Konum). Web push gibi şeyler için, izin istemenin başka bir alt etki alanında kullanıcı tarafından kabul edilip edilmediğini tekrar talep etmemek için izleyebileceğiniz bir çerez kullanabilirsiniz.

Kurulum

Bir PWA yüklemek için her orijin bir kendi manifestosunu olmalıdır start_urlolduğunu kendisine göreli . Bu, belirli bir kaynaktan (yani:) kurulum istemini alan bir kullanıcının http://section.example.comPWA’yı start_urlfarklı birine (yani 🙂 kuramayacağı anlamına gelir http://www.example.com. Başka bir deyişle, bir alt etki alanı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.

Basit bir geçici çözüm, start_urlana menşe yönlendirme ile bir kullanmaktır . Örneğin: alt etki http://section.example.com, bir tanımlayabilirsiniz start_urlait http://section.example.com/pwabir yönlendirme içeren,: http://www.example.com, kullanıcı her zaman ana sayfada iniş yapma.

Ayrıca, her bir alt etki alanı yükleme ölçütlerini karşılıyorsa ve kullanıcıdan PWA’yı yüklemesini isterse, aynı kullanıcının birden çok yükleme isteminde bulunabileceği sorusu da vardır .

Aşağıdaki tekniklerden birini uygulayarak bu sorunu azaltın:

İstemi tek bir alanda gösterme: Sitede yükleme ölçütlerini geçen birçok alt alan varsa , istemin sitenin istenmeyen kısımlarında görünmesini önlemek için ( burada açıklandığı gibi ) beforeinstallpromptolay kullanılabilir ve preventDefault()çağrılabilir. diğer kısımlarda göstermeye devam ederken (örneğin, ana sayfa).

Farklı alt alan adlarında istemi bir kez gösterme: Her alt alan adının yükleme istemini göstermesine izin vermek de mümkündür. (Bazı alt alanlar daha sık ziyaret edildiğinde bu anlamlı olabilir). Bu durumda, istemi bir kullanıcıya birden çok kez göstermekten kaçınmak önemlidir. Bu amaçla, bilgi istemi gösterilip gösterilmediğini izlemek ve beforeinstallpromptetkinlik tetiklendiğinde varlığını kontrol etmek için bir çerez kullanılabilir . Tanımlama bilgisi mevcutsa, kullanıcının tekrar istemi preventDefault()önlemek için istemi başka bir yere zaten götürdüğü, bu nedenle aranabileceği anlamına gelir .

Bağımsız mod

Bağımsız bir pencerede gezinirken, kullanıcı PWA’nın bildirdiği şekilde belirlenen kapsam dışına çıktığında tarayıcı farklı davranacaktır. Davranış, her tarayıcı sürümüne ve satıcısına bağlıdır. Örneğin, en son Chrome sürümleri , bir kullanıcı tam ekran modunda kapsam dışına çıktığında bir Chrome özel sekmesi açar .

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

Yeni URL, http://login.example.comtam ekran iframe içinde açılabilir.
Görev iframe içinde tamamlandıktan sonra (örneğin, giriş işlemi), iframe’den gelen herhangi bir bilgiyi üst sayfaya geri iletmek için postMessage () kullanılabilir.

Son adım olarak, mesaj ana sayfa tarafından alındıktan sonra, dinleyiciler kayıt dışı bırakılabilir ve iframe sonunda DOM’dan kaldırılabilir.
Dikkat: Önceki teknik, kullanıcının bir alt etki alanında bir eylem gerçekleştirebileceği ve ana orijine geri dönebileceği (bir giriş akışında olduğu gibi), sitenin küçük bir bölümündeki olası UI değişikliğini azaltmaya yardımcı olabilir; Alt etki alanlarında barındırılan birçok sayfa (site bölümlerinin tamamı gibi) dahil olmak üzere, tüm yollar için uygulanacak verimli teknik.

Sonuç

Aynı köken politikası, tutarlı bir PWA deneyimi elde etmek isteyen birçok köken üzerine kurulu siteler için birçok kısıtlama getirmektedir. Bu nedenle, kullanıcılara en iyi deneyimi sunmak için, siteleri farklı kökenlere bölmemek için şiddetle tavsiye ediyoruz.

Halihazırda bu şekilde inşa edilmiş olan siteler için, çok kaynaklı PWA’ların doğru çalışmasını sağlamak zor olabilir, ancak bazı olası geçici çözümleri araştırdık. Her biri takaslarla gelebilir, bu nedenle web sitenizde hangi yaklaşımı kullanacağınıza karar verirken kararınızı kullanın.

Uzun vadeli bir stratejiyi veya sitenin yeniden tasarımını değerlendirirken, çok kaynaklı mimariyi korumak için önemli bir neden olmadıkça, tek bir kökene geçmeyi düşünün.