Mimari

Uygulamanızı PWA'ları güvenilir, yüklenebilir ve özellikli hale getiren teknolojiden en iyi şekilde yararlanacak şekilde tasarlamak için ilk adım, uygulamanızı ve onun kısıtlamalarını anlamak 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 (MPA'lar).

Tek sayfalık uygulamalar, bir sayfanın HTML oluşturma işleminin büyük kısmının veya tamamının, uygulama tarafından alınan veya uygulama için sağlanan verilere dayalı olarak istemci taraflı JavaScript kontrolüne sahip olmasıyla 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, genellikle tarayıcının HTML'yi yüklemesi tamamlandıktan 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ız ve bağlamınız için doğru yöntemi seçmek, kullanıcılarınıza hızlı ve güvenilir bir deneyim sağlamanın anahtarıdır.

Tek sayfalık uygulamalar

Tek sayfalık uygulamalar, aşağıdaki durumlarda mimariye uygundur:

• Kullanıcı etkileşimi, temel olarak aynı sayfada görüntülenen, birbirine bağlı verilerin atomik güncellemelerine (ör. gerçek zamanlı veri kontrol paneli veya video düzenleme uygulaması) odaklanır.
• Uygulamanızda, yalnızca istemci tarafı başlatma bağımlılıkları vardır (ör. aşırı yüksek başlatma maliyetine sahip üçüncü taraf kimlik doğrulama sağlayıcısı).
• Bir görünümün yüklenmesi için gereken veriler, yalnızca istemci taraflı belirli bir bağlama bağlıdır (ör. bağlı bir donanım parçasının denetimlerini görüntüleme).
• Uygulama, boyutu ve karmaşıklığı yukarıda belirtilen dezavantajları etkilemeyecek kadar küçük ve basittir.

Aşağıdaki durumlarda SPA'lar iyi bir mimari tercihi olmayabilir:

• İlk yükleme performansı önemlidir. SPA'ların, neyin yükleneceğini ve nasıl görüntüleneceğini belirlemek için genellikle daha fazla JavaScript yüklemesi gerekir. İçerik alma ile birlikte bu JavaScript'in ayrıştırılma ve yürütme süresi, oluşturulmuş HTML'yi göndermekten daha yavaştır.
• Uygulamanız çoğunlukla düşük veya ortalama enerjiye sahip cihazlarda çalışıyor. SPA'lar oluşturma işlemi için JavaScript'e bağlı olduğundan, kullanıcı deneyimi söz konusu cihazların gücüne MPA'ya kıyasla çok daha fazla bağlıdır.

SPA'lar, tarayıcının yerleşik gezinme sistemini yönlendirmeyle değiştirmeleri gerektiğinden, SPA'lar mevcut görünümü etkili bir şekilde güncelleme, gezinme değişikliklerini yönetme ve normalde tarayıcı tarafından işlenecek önceki görünümleri temizleme konularında minimum düzeyde karmaşıklığa ihtiyaç duyar. Bu da genel olarak bakımlarını zorlaştırır ve kullanıcının cihazında daha fazla vergi verilmesini sağlar.

Çok sayfalı uygulamalar

Çok sayfalı uygulamalar, aşağıdaki durumlarda iyi bir mimari tercihidir:

• Kullanıcı etkileşimi çoğunlukla, isteğe bağlı bağlama dayalı veriler içeren tek bir veri parçasının (ör. haber veya e-ticaret uygulaması) görüntülenmesi etrafında şekillenir.
• İlk oluşturma hızı önemlidir çünkü zaten 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ıdır.
• İstemci tarafı etkileşimi veya bağlamı, ilk yüklemeden sonra geliştirme olarak dahil edilebilir. Örneğin, oluşturulan bir sayfaya bir profil katman olarak eklenebilir veya istemci tarafında bağlama bağlı ikincil bileşenler eklenebilir.

Aşağıdaki durumlarda MPA'lar iyi bir mimari tercihi olmayabilir:

• JavaScript veya CSS'nizin yeniden indirilmesi, yeniden ayrıştırılması ve yeniden çalıştırılması aşırı derecede pahalı bir işlemdir. Bu dezavantajları, Service Worker'lar sayesinde PWA'larda (Progresif Web Uygulaması) azaltır.
• Kullanıcının 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. Kodun yakalanıp alınması ya da görünümler arasında yeniden talep edilmesi gerekir.

Bağımsız görünümlerin bir sunucu tarafından dinamik olarak oluşturulması veya erişimden önce önceden oluşturulması gerektiğinden, bu durum barındırmayı veya veri karmaşıklığını artırabilir.

Hangisini seçmelisiniz?

Bu avantajlar ve dezavantajlar olsa bile her iki mimari de PWA'nızı oluşturmak için geçerlidir. Hatta bunların ihtiyaçlarına bağlı olarak uygulamanızın farklı bölümleri için de kullanabilirsiniz. Örneğin, mağaza girişlerinin MPA mimarisini, ödeme akışının ise SPA mimarisini izlemesini sağlayabilirsiniz.

Seçim ne olursa olsun 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ın ve ağ yanıtlarının temel yönlendirme ve tesliminin ötesinde çok fazla güce sahiptir. Kullanıcı 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 "Service Worker Dahildir" (SWI) kalıbı. 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 bir araya getirir.

Bu resim, örnek bir web sayfasıdır. Sayfayı aşağıdaki bölümlere ayıran beş farklı bölümü vardır:

• Genel düzen.
• Genel üstbilgi (üstteki koyu çubuk).
• İçerik alanı (sol ortadaki çizgiler ve resim).
• Kenar çubuğu (sağ ortada yer alan uzun, orta koyulukta çubuk).
• Altbilgi (koyu renkli alt çubuk).

Genel düzen

Genel düzenin sık 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 altbilgi, üst menü ve site altbilgisi gibi öğeleri içerir ve belirli bir zorluğu da beraberinde getirir: Sayfanın bir bütün olarak önbelleğe alınması gerekiyorsa bunlar, söz konusu sayfanın ne zaman önbelleğe alındığına bağlı olarak, sayfa yüklemeleri arasında değişebilir.

Bunları birbirinden ayırıp içerikten bağımsız olarak önbelleğe alarak kullanıcıların önbelleğe ne zaman çekildiklerine bakılmaksızın her zaman aynı sürümü alacaklarından emin olabilirsiniz. Bu bağlantılar nadiren güncellendikleri için önbelleğe alma için de iyi birer adaydır. Fakat bir bağımlılıkları vardır: sitenin CSS ve JavaScript'i.

CSS ve JavaScript

İdeal olarak, önceden önbelleğe alınan öğelerde olduğu gibi, Service Worker'ın güncellenmesine gerek kalmadan, artımlı güncellemelere izin vermek için stratejinin yeniden doğrulanması sırasında sitenin CSS ve JavaScript'inin önbelleğe alınması gerekir. Yine de Service Worker yeni bir genel üstbilgi veya altbilgiyle güncellendiğinde, bunların da en düşük 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 sırasında verilerin eski olması iyi bir stratejidir. Resimler, daha önce açıklandığı gibi, ilk ö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çerikler barındırdığı varsayılırsa, ağdan veri almaya yetecek kadar kritik değildir. Bunun için yeniden doğrulama stratejisi kullanılır.

Şimdi, tüm bunların ardından, tek sayfalık uygulamalar için bölüm başına bu tür önbelleğe alma işlemlerini yalnızca yapabileceğinizi düşünebilirsiniz. Ancak hizmet çalışanınızda uç tarafı içerirler veya sunucu tarafı içerikleri'nden esinlenen kalıpları kullanarak ve bazı gelişmiş Service Worker özellikleriyle birlikte bunu her iki mimaride de yapabilirsiniz.

Kendiniz deneyin

Bir sonraki codelab'de Service Worker'ın eklemeyi deneyebilirsiniz:

Yanıtları akış şeklinde gösterme

Önceki sayfa, SPA dünyasında uygulama kabuğu modeli kullanılarak oluşturulabiliyordu. Burada uygulama kabuğu önbelleğe alınıp ardından sunulacak ve içerik istemci tarafında yüklenebiliyordu. Streams API'nin kullanıma sunulması ve 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 önbelleğe alma esnekliğini MPA'ların hızıyla elde edebilirsiniz.

Bunu aşağıdaki nedenlerle yapar:

• Akışlar eşzamansız olarak oluşturulabilir ve böylece akışın farklı parçalarının başka kaynaklardan gelmesini sağlayabilir.
• Akış isteğinde bulunan kullanıcı, tüm öğenin tamamlanmasını beklemek yerine, ilk veri parçası 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ışı tamamlanmadan önce kademeli olarak görüntüleyebilir.

Akışın bu üç özelliği sayesinde, akışı temel alan mimariler genellikle akışa kıyasla daha hızlı algılanır.

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 Workbox modülü var.

Alanlar, kaynaklar ve PWA kapsamı

Service Worker'lar, depolama alanı ve yüklü bir PWA penceresi 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. Veriler izole edilir ve farklı kaynaklar arasında erişilemez.

Aynı kaynak politikası

Protokol, bağlantı noktası ve ana makine aynıysa iki URL tam 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.

Barındırıcı, alt alan adlarını değiştirmek için tek yöntem değildir. Her ana makine, bir üst düzey alan (TLD), ikincil düzey alan (SLD) ve aradaki noktalarla ayrılmış ve bir URL'de sağdan sola doğru okunan sıfır ya da daha fazla etiketten (bazen alt alan adları da denir) oluşur. Öğelerden herhangi birinde değişiklik yapıldığında farklı bir ana makine oluşur.

Pencere yönetimi modülünde, kullanıcı 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ı, web siteleri farklı kaynaklar olarak kabul edildiğinden farklı etiketlerle aynı TLD ve SLD'ye sahip olsa bile görünür.

Web'e göz atma bağlamında bir kaynağın temel özelliklerinden biri, depolama alanı ve izinlerin işleyiş şeklidir. Bir kaynak, içerdiği tüm içerikler ve PWA'lar arasında birçok özelliğe sahiptir. Örneğin:

• Depolama kotası ve verileri (IndexedDB, çerezler, web depolama alanı, önbellek depolama alanı).
• Hizmet çalışanı 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şim iptal edilir. Bu nedenle izinleri tekrar vermeniz gerekir ve PWA'nız depolama alanında kayıtlı tüm verilere erişemez.

Kaynaklar

• SPA'ların Ötesinde: PWA'nız için alternatif mimariler
• Progresif web uygulamalarının yapısı
• Akışlar: Ayrıntılı kılavuz