Service Worker'ları kullanan herkes, bunların tamamen eşzamansız olduğunu söyleyebilir. Bu modeller, yalnızca FetchEvent gibi etkinlik tabanlı arayüzlerden yararlanır ve eşzamansız işlemler tamamlandığında sinyal vermek için vaatler kullanır.
Hizmet çalışanının getirme etkinlik işleyicisi tarafından sağlanan yanıtlar söz konusu olduğunda eşzamansızlık da geliştirici tarafından daha az görülse de aynı derecede önemlidir. Akış yanıtları burada altın standarttır: Orijinal isteği yapan sayfanın, ilk veri parçası kullanılabilir olur olmaz yanıtla çalışmaya başlamasını sağlar ve içeriği kademeli olarak görüntülemek için akış için optimize edilmiş ayrıştırıcılar kullanabilir.
Kendi fetch etkinlik işleyicinizi yazarken, fetch() veya caches.match() aracılığıyla aldığınız respondWith() yöntemini Response
(veya Response için bir söz) ileterek
bir günlük adlandırma yaygın olarak kullanılmaktadır. Neyse ki bu yöntemlerin her ikisi tarafından oluşturulan Response
zaten akışlı durumda. Kötü haber ise "manuel olarak"
oluşturulmuş
Response'lar en azından şu ana kadar akış olarak yayınlanamamaktadır. Burası, Streams API'nin devreye girdiği yerdir.
Canlı yayınlar mı?
Akış, artımlı olarak oluşturulabilen ve değiştirilebilen bir veri kaynağıdır ve eşzamansız veri parçalarını okumak veya yazmak için bir arayüz sağlar. Bu parçaların yalnızca bir kısmı herhangi bir zamanda bellekte kullanılabilir olabilir. Şimdilik fetchEvent.respondWith() öğesine aktarılan bir Response nesnesi oluşturmak için kullanılabilecek ReadableStream ile ilgileniyoruz:
self.addEventListener('fetch', event => {
var stream = new ReadableStream({
start(controller) {
if (/* there's more data */) {
controller.enqueue(/* your data here */);
} else {
controller.close();
}
});
});
var response = new Response(stream, {
headers: {'content-type': /* your content-type here */}
});
event.respondWith(response);
});
İsteği fetch etkinliğini tetikleyen sayfa, event.respondWith() çağrılır çağrılmaz geri bir akış yanıtı alır ve hizmet çalışanı ek verileri enqueue()işleme devam ettiği sürece sayfa, bu akıştan okumaya devam eder. Service Worker'dan sayfaya gönderilen yanıt tamamen eşzamansızdır ve akışın doldurulması üzerinde tam kontrole sahibiz.
Gerçek hayattaki kullanımlar
Muhtemelen önceki örneğin bazı yer tutucu /* your data here */ yorumları olduğunu ve gerçek uygulama ayrıntılarına yeterince değinilmediğini fark etmişsinizdir.
Peki, gerçek hayattan bir örnek nasıl olur?
Jake Archibald (beklenmedik bir şekilde!), önbelleğe alınmış birden fazla HTML snippet'inden gelen bir HTML yanıtını ve fetch() üzerinden akışı yapılan "canlı" verilerle bir araya getirmek için akışları kullanma konusunda mükemmel bir örnek sunuyor.
Jake'in de açıkladığı gibi akış yanıtı kullanmanın avantajı, tarayıcının tüm blog içeriğinin getirilmesini beklemek zorunda kalmadan, önbellekten hızlı bir şekilde yüklenen ilk bit de dahil olmak üzere HTML'yi akış olarak ayrıştırıp oluşturabilmesidir. Bu, tarayıcının progresif HTML oluşturma özelliklerinden tam olarak yararlanır. Bazı resim ve video biçimleri gibi kademeli olarak oluşturulabilen diğer kaynaklar da bu yaklaşımdan yararlanabilir.
Canlı yayınlar mı? Yoksa uygulama kabukları mı?
Web uygulamalarınızı güçlendirmek için Service Worker'ları kullanmayla ilgili mevcut en iyi uygulamalar App Shell + dinamik içerik modeline odaklanır. Bu yaklaşım, web uygulamanızın "kabuğunun" (yapınızı ve düzeninizi görüntülemek için gereken minimum HTML, JavaScript ve CSS) etkin bir şekilde önbelleğe alınmasına ve ardından istemci taraflı istek aracılığıyla her bir belirli sayfa için gereken dinamik içeriğin yüklenmesine dayanır.
Akışlar, App Shell modeline bir alternatif sunar. Bu modelde, bir kullanıcı yeni bir sayfaya gittiğinde tarayıcıya daha dolu bir HTML yanıtı aktarılır. Akışlı yanıt, önbelleğe alınan kaynaklardan yararlanabilir; böylece çevrimdışıyken bile ilk HTML parçasını hızlı bir şekilde sağlayabilir. Ancak sonuçta daha çok geleneksel, sunucu tarafından oluşturulan yanıt gövdeleri gibi görünür. Örneğin, web uygulamanız, kısmi şablonları birleştirerek HTML'yi sunucu tarafından oluşturan bir içerik yönetim sistemi tarafından destekleniyorsa bu model, doğrudan akış yanıtlarını kullanmaya dönüşür. Bunun için şablon oluşturma mantığı, sunucunuz yerine Service Worker'da oluşturulur. Aşağıdaki videoda gösterildiği gibi, bu kullanım alanı için akışlı yanıtların sunduğu hız avantajı çarpıcı olabilir:
Tüm HTML yanıtını akış şeklinde sunmanın önemli bir avantajı, neden videodaki en hızlı alternatif olduğunu açıklamaktır, ilk gezinme isteği sırasında oluşturulan HTML, tarayıcının akış HTML ayrıştırıcısından tam olarak yararlanabilir. Sayfa yüklendikten sonra dokümana eklenen HTML yığınları (App Shell modelinde yaygın olarak olduğu gibi) bu optimizasyondan yararlanamaz.
Peki hizmet çalışanı uygulamanızın planlama aşamalarındaysanız hangi modeli benimsemelisiniz: kademeli olarak oluşturulan akışlı yanıtlar mı yoksa dinamik içerik için istemci tarafı isteğiyle birlikte hafif bir kabuk mu? Beklendiği gibi bu sorunun cevabı şuna göre değişir: İYS ve kısmi şablonlara (avantaj: akış) dayalı mevcut bir uygulamanız olup olmamasına, progresif oluşturmadan fayda sağlayacak tek, büyük HTML yükleri isteyip istemediğinize (avantaj: akış) web uygulamanızın tek sayfalık kararlı uygulama olarak modellenip modellenmediğine (avantaj: App Shell'in desteklediği birden fazla tarayıcı modelinde desteklenip desteklenmediğine) bağlı olarak değişir.
Hala hizmet çalışanlarının desteklediği akış yanıtlarının en ilk günlerindeyiz ve farklı modellerin olgun olduğunu görmeyi ve özellikle de yaygın kullanım alanlarını otomatikleştirmek için daha fazla araç geliştirmeyi dört gözle bekliyoruz.
Canlı yayınların ayrıntılarına inme
Kendi okunabilir akışlarınızı oluşturuyorsanız, controller.enqueue() kodunu rastgele çağırmak yeterli veya verimli olmayabilir. Cem, kullanım alanınıza uygun bir veri akışı oluşturmak için start(), pull() ve cancel() yöntemlerinin koordineli olarak nasıl kullanılabileceği hakkında bazı ayrıntıları açıklıyor.
Daha fazla ayrıntıya ihtiyacınız varsa Akışlar spesifikasyonlarını inceleyebilirsiniz.
Uyumluluk
Kaynak Chrome 52'de ReadableStream kullanarak hizmet çalışanı içinde Response nesnesi oluşturma desteği eklendi.
Firefox'un hizmet çalışanı uygulaması, ReadableStream tarafından desteklenen yanıtları henüz desteklememektedir. Ancak Streams API desteği için takip edebileceğiniz ilgili bir izleme hatası vardır.
Edge'deki öneksiz Streams API desteğinin ilerlemesi ve genel hizmet çalışanı desteği, Microsoft'un Platform durumu sayfasından takip edilebilir.