Uygulamanızı, PWA'ları güvenilir, yüklenebilir ve kullanılabilir hale getiren teknolojiden en iyi şekilde yararlanacak şekilde tasarlamanın ilk adımı, uygulamanızı ve kısıtlamalarını anlamanız ve her ikisi için de uygun bir mimari seçmektir.
SPA ve MPA karşılaştırması
Günümüzde web geliştirmede iki temel mimari kalıbı vardır: tek sayfalık uygulamalar (SPA'lar ve çok sayfalı uygulamalar veya MPA'lar).
Tek sayfalık uygulamalar, uygulama tarafından alınan veya uygulamaya sağlanan verilere dayalı olarak bir sayfanın HTML oluşturmanın büyük kısmının veya tamamının istemci tarafında JavaScript tarafından kontrol edilmesiyle tanımlanır. Uygulama, tarayıcının yerleşik gezinme işlevini geçersiz kılarak bunun yerine yönlendirme ve görüntüleme işleme işlevselliğini alır.
Çok sayfalı uygulamalarda genellikle doğrudan tarayıcıya gönderilen önceden oluşturulmuş HTML bulunur. Bu HTML, genellikle tarayıcı HTML'yi yüklemeyi bitirdikten sonra istemci tarafı JavaScript ile iyileştirilir ve sonraki görüntülemeleri görüntülemek için tarayıcının yerleşik gezinme mekanizmalarını kullanır.
PWA'lar oluşturmak için her iki mimari de kullanılabilir.
Her birinin avantajları ve dezavantajları vardır. Kullanım alanınıza ve bağlamınıza uygun biçimi seçmek, kullanıcılarınıza hızlı ve güvenilir bir deneyim sunmanın anahtarıdır.
Tek sayfalık uygulamalar
- Çoğunlukla atomik sayfa içi güncellemeler.
- Başlangıçta yüklenen istemci tarafı bağımlılıkları.
- Önbellek kullanımı nedeniyle sonraki yüklemeler hızlıdır.
- İlk yükleme maliyetinin yüksek olması.
- Performans, cihaz donanımına ve ağ bağlantısına bağlıdır.
- Daha fazla uygulama karmaşıklığı gerekiyor.
Tek sayfalık uygulamalar, aşağıdaki durumlarda mimari açıdan iyi bir uyumdur:
- Kullanıcı etkileşimi, temel olarak aynı sayfada görüntülenen, birbirine bağlı verilerin atomik güncellemeleri etrafında şekillenir. Örneğin, gerçek zamanlı bir veri kontrol paneli veya bir video düzenleme uygulaması.
- Uygulamanızın, aşırı yüksek başlatma maliyetine sahip üçüncü taraf kimlik doğrulama sağlayıcısı gibi yalnızca istemci tarafı başlatma bağımlılıkları vardır.
- Bir görünümün yüklenmesi için gereken veriler, yalnızca istemci tarafı bağlamına dayanır. Örneğin, bağlı bir donanım parçasına yönelik denetimler görüntülenir.
- Uygulama, boyutu ve karmaşıklığı yukarıda belirtilen dezavantajları etkilemeyecek kadar küçük ve basittir.
Aşağıdaki durumlarda SPA'lar iyi bir mimari seçim olmayabilir:
- İlk yükleme performansı önemlidir. SPA'ların genellikle neyin yükleneceğini ve nasıl görüntüleneceğini belirlemek için daha fazla JavaScript yüklemesi gerekir. Bu JavaScript'in ayrıştırılma ve çalıştırılma süresi, içerik almayla birlikte, oluşturulmuş HTML'yi göndermekten daha uzundur.
- Uygulamanız çoğunlukla düşük ve ortalama performansa sahip cihazlarda çalışıyor. SPA'lar oluşturma için JavaScript'e bağlı olduğundan, kullanıcı deneyimi, MPA'da olduğundan çok daha önemli ölçüde kullanıcıların kendilerine özgü cihazlarının gücüne bağlıdır.
SPA'lar, tarayıcının yerleşik gezinme işlevini kendi yönlendirmeleriyle değiştirmeleri gerektiğinden, geçerli görünümü etkili bir şekilde güncelleme, gezinme değişikliklerini yönetme ve tarayıcı tarafından işlenecek önceki görünümleri temizleme konularında en az düzeyde karmaşıklığa ihtiyaç duyar.
Çok sayfalı uygulamalar
- Çoğunlukla tam sayfa güncellemeler.
- İlk oluşturma hızı önemlidir.
- İstemci tarafı komut dosyası çalıştırma bir geliştirme olabilir.
- İkincil görünümler için başka bir sunucu çağrısı gerekir.
- Bağlam, görünümler arasında taşınmaz.
- Sunucu veya önceden oluşturma gerektirir.
Aşağıdaki durumlarda çok sayfalı uygulamalar iyi bir mimari seçimdir:
- Kullanıcı etkileşimi, temel olarak isteğe bağlı bağlama dayalı veriler (ör. haber veya e-ticaret uygulaması) içeren tek bir veri parçasının görüntülenmesi etrafında şekillenir.
- Önceden oluşturulmuş HTML'yi tarayıcıya göndermek, JavaScript tabanlı bir alternatifi yükledikten, ayrıştırıldıktan ve çalıştırdıktan sonra veri isteğinden derlemekten daha hızlı olduğundan ilk oluşturma hızı önemlidir.
- İlk yüklemeden sonra geliştirme olarak istemci tarafı etkileşimi veya bağlam eklenebilir. Örneğin, oluşturulan bir sayfaya profil katmanları eklenmesi veya istemci tarafında bağlama bağlı ikincil bileşenler eklenmesi.
Aşağıdaki durumlarda MPA'lar iyi bir mimari seçim olmayabilir:
- JavaScript veya CSS'nizi yeniden indirmek, yeniden ayrıştırmak ve yeniden çalıştırmak aşırı derecede pahalı bir işlemdir. Bu olumsuz durum, Service Worker'lar kullanılarak PWA'larda azaltılır.
- Kullanıcı konumu gibi istemci tarafı bağlamı, görüntülemeler arasında sorunsuz bir şekilde aktarılmaz ve bu bağlamı yeniden elde etmek pahalı olabilir. Bu verilerin yakalanıp alınması veya görüntülemeler arasında yeniden istenmesi gerekir.
Ayrı görünümlerin bir sunucu tarafından dinamik olarak oluşturulması veya erişimden önce önceden oluşturulması gerektiğinden, barındırmayı sınırlandırabilir veya veri karmaşıklığını artırabilirsiniz.
Hangisini seçmelisiniz?
Bu avantajlar ve dezavantajlar olsa bile her iki mimari de PWA'nızı oluşturmak için geçerlidir. Hatta uygulamanızın ihtiyaçlarına bağlı olarak farklı bölümleri için iki ayrı uygulama kullanabilirsiniz. Örneğin, mağaza girişlerinin MPA mimarisini, ödeme akışının ise SPA mimarisini izlemesi gibi.
Seçimden bağımsız olarak bir sonraki adım, en iyi deneyimi sunmak için Service Worker'lardan nasıl en iyi şekilde yararlanacağınızı anlamaktır.
Service Worker'ın gücü
Service Worker, önbelleğe alınan yanıtlar ve ağ yanıtlarının temel yönlendirme ve tesliminin ötesinde çok fazla güce sahiptir. Kullanıcının deneyimini ve performansını iyileştirebilecek karmaşık algoritmalar oluşturabiliriz.
Hizmet çalışanı şunları içerir (SWI)
Service Worker'ları site mimarisinin ayrılmaz bir parçası olarak kullanmak için yaygınlaşan bir yöntem, Service Worker içerir (SWI) şeklindedir. SWI, genellikle bir HTML sayfası olan öğeleri önbelleğe alma ihtiyaçlarına göre parçalara ayırır. Ardından, önbellek boyutunu küçültürken tutarlılığı, performansı ve güvenilirliği artırmak için öğeleri Service Worker'da tekrar birleştirir.
Bu resim, örnek bir web sayfasıdır. Sayfayı ikiye ayıran beş farklı bölümü vardır:
- Genel düzen.
- Genel üstbilgi (üstteki koyu renkli çubuk).
- İçerik alanı (sol ortadaki çizgiler ve resim).
- Kenar çubuğu (sağ orta kısımda uzun, orta koyu renk çubuk).
- Altbilgi (koyu renkli alt çubuk).
Genel düzen
Genel düzenin çok sık değişme olasılığı düşüktür ve herhangi bir bağımlılığı yoktur. Önbelleğe alma için iyi bir adaydır.
Başlık ve alt bilgi
Genel üstbilgi ve altbilgide üst menü ve site altbilgisi gibi öğeler bulunur ve bu durum belirli bir zorluğu da beraberinde getirir: Sayfa bir bütün olarak önbelleğe alınacaksa bu durum, ilgili sayfanın önbelleğe alındığı zamana bağlı olarak sayfa yüklemeleri arasında değişebilir.
Bunları içerikten ayırarak ve önbelleğe alarak, önbelleğe alındıkları tarihten bağımsız olarak kullanıcıların her zaman aynı sürümü almasını sağlayabilirsiniz. Nadiren güncellendikleri için önbelleğe alma için de iyi birer adaydırlar. Ancak bir bağımlılıkları vardır: sitenin CSS ve JavaScript'i.
CSS ve JavaScript
İdeal olarak, sitenin CSS ve JavaScript'i eski bir önbellekle önbelleğe alınmalıdır. Aynı zamanda, önceden önbelleğe alınmış öğelerde olduğu gibi, Service Worker'ın güncellenmesine gerek kalmadan artımlı güncellemelere izin vermek için stratejiyi yeniden doğrulayabilirsiniz. Yine de Service Worker yeni bir genel üstbilgi veya altbilgi ile her güncellendiğinde, bunların da minimum sürümde tutulmaları gerekir. Bu nedenle, hizmet çalışanı yüklendiğinde önbelleklerinin de öğelerin en son sürümüyle güncellenmesi gerekir.
İçerik alanı
Sırada içerik alanı var. Güncellemelerin sıklığına bağlı olarak burada önce ağ öncelikli veya yeniden doğrulama için eski olması iyi bir stratejidir. Resimler, daha önce bahsedildiği gibi, öncelikli önbellek stratejisiyle önbelleğe alınmalıdır.
Kenar çubuğu
Son olarak, kenar çubuğu içeriğinin etiketler ve ilgili öğeler gibi ikincil içerik barındırdığı varsayıldığında, bu içerik ağdan alınacak kadar kritik değildir. Eski ve yeniden doğrulama stratejisi bunun için uygundur.
Şimdi, tüm bunların üzerinden geçtikten sonra, tek sayfalık uygulamalarda yalnızca bu bölüm başına önbelleğe alma işlemi yapabileceğinizi düşünebilirsiniz. Ancak Service Worker'ınızda Uç taraflı öğeler veya sunucu tarafı özellikleri'nden ilham alan kalıpları benimseyerek ve bazı gelişmiş Service Worker özellikleriyle bunu her iki mimaride de yapabilirsiniz.
Kendiniz deneyin
Bir sonraki codelab'de Service Worker'ın dahil edilmesini deneyebilirsiniz:
Yanıt akışı
Önceki sayfa, SPA dünyasında uygulama kabuğu modeli kullanılarak oluşturulabiliyordu. Bu modelde uygulama kabuğu önbelleğe alınır, ardından sunulur ve içerik istemci tarafında yüklenir. Streams API'nin kullanıma sunulması ve daha geniş bir kitlenin kullanımına sunulmasıyla birlikte, hem uygulama kabuğu hem de içerik Service Worker'da birleştirilebilir ve tarayıcıya aktarılabilir. Böylece, uygulama kabuğunun MPA hızında önbelleğe alma esnekliğine sahip olursunuz.
Bunu aşağıdaki nedenlerle yapar:
- Akışlar eşzamansız olarak oluşturulabilir ve bu da akışın farklı parçalarının başka kaynaklardan gelmesini sağlar.
- Akış isteğinde bulunan kullanıcı, tüm öğenin tamamlanmasını beklemek yerine, ilk veri grubu kullanılabilir olur olmaz yanıt üzerinde çalışmaya başlayabilir.
- Tarayıcı da dahil olmak üzere akış için optimize edilmiş ayrıştırıcılar, yanıtın algılanan performansını hızlandırarak akışın içeriğini tamamlanmadan önce kademeli olarak görüntüleyebilir.
Akışın bu üç özelliği sayesinde akış odaklı mimariler, diğerlerine göre genellikle daha hızlı algılanan performansa sahiptir.
Streams API, karmaşık ve düşük seviyeli olduğundan zorlayıcı olabilir. Neyse ki hizmet çalışanlarınız için akış yanıtlarını ayarlamanıza yardımcı olabilecek bir Çalışma Kutusu modülü bulunmaktadır.
Alanlar, kaynaklar ve PWA kapsamı
Service Worker'lar, depolama alanı ve yüklü bir PWA penceresi de dahil olmak üzere web çalışanları, web'deki en önemli güvenlik mekanizmalarından biri olan "aynı kaynak" politikasına tabidir. Aynı kaynakta izinler verilir, veriler paylaşılabilir ve hizmet çalışanı farklı istemcilerle konuşabilir. Aynı kaynağın dışında, izinler otomatik olarak verilmez ve veriler birbirinden izole edilir ve farklı kaynaklar arasında erişilemez.
Aynı kaynak politikası
Protokol, bağlantı noktası ve ana makine aynıysa iki URL aynı kaynağa sahip olarak tanımlanır.
Örneğin: https://squoosh.app
ve https://squoosh.app/v2
aynı kaynağa sahipken http://squoosh.app
, https://squoosh.com
, https://app.squoosh.app
ve https://squoosh.app:8080
farklı kaynaklara sahip. Daha fazla bilgi ve örnek için aynı kaynak politikası MDN referansını inceleyin.
Bir ana makine değiştirebileceği tek yol alt alan adlarını değiştirmek değildir. Her ana makine; bir üst düzey alan (TLD), ikincil düzey alan (SLD) ve sıfır veya daha fazla etiketten (bazen alt alan adı da denir) oluşur. Etiket, aralarına noktalarla ayrılmış ve sağdan sola doğru okunarak URL'yi gösterir. Öğelerden herhangi birinde değişiklik yapılması farklı bir ana makineye neden olur.
Pencere yönetimi modülünde, kullanıcılar yüklü bir PWA'dan farklı bir kaynağa gittiğinde uygulama içi tarayıcının nasıl göründüğünü görmüştük.
Söz konusu uygulama içi tarayıcı, farklı kaynaklar olarak kabul edilen web siteleri aynı TLD ve SLD'ye, ancak farklı etiketlere sahip olsa bile gösterilir.
Web'e göz atma bağlamında bir kaynağın en önemli unsurlarından biri, depolama alanı ve izinlerin işleyiş şeklidir. Bir kaynak, tüm içerikler ve PWA'lar arasında birçok özelliğe sahiptir. Örneğin:
- Depolama kotası ve veri (IndexedDB, çerezler, web depolama, önbellek depolama).
- Service Worker kayıtları.
- Verilen veya reddedilen izinler (ör. web push, coğrafi konum, sensörler).
- Web push kayıtları.
Bir kaynaktan diğerine geçtiğinizde önceki tüm erişimler iptal edilir. Bu nedenle, izinlerin tekrar verilmesi gerekir ve PWA'nız depolama alanında kayıtlı tüm verilere erişemez.