Hizmet işçilerini kullanan herkes, bunların tamamen eşzamansız olduğunu söyleyebilir. Yalnızca FetchEvent gibi etkinlik tabanlı arayüzleri kullanır ve asenkron işlemlerin tamamlandığını belirtmek için promises'ı kullanır.
Bir hizmet çalışanının getirme etkinlik işleyicisi tarafından sağlanan yanıtlar söz konusu olduğunda, geliştirici tarafından daha az fark edilse de asynkronite de aynı derecede önemlidir. Burada akış yanıtları altın standarttır: Orijinal isteği yapan sayfanın, ilk veri parçası kullanılabilir hale gelir gelmez yanıtla çalışmaya başlamasına olanak tanır 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, respondWith()
yöntemine fetch() veya caches.match() üzerinden aldığınız bir Response (veya Response için bir söz) aktarıp işleri bitirmek yaygın bir uygulamadır. İyi haber şu ki, bu iki yöntemle oluşturulan Response'ler zaten aktarılabilir durumda. Kötü haber ise "manuel olarak" oluşturulan
Response'lerin, en azından şimdilik aktarılamıyor olması. İşte bu noktada Streams API devreye girer.
Akışlar?
Akış, artımlı olarak oluşturulup değiştirilebilen bir veri kaynağıdır ve herhangi bir zamanda yalnızca bir alt kümesinin bellekte bulunabileceği, asenkron veri parçalarını okumak veya yazmak için bir arayüz sağlar. Şimdilik, fetchEvent.respondWith()'ye iletilen bir Response nesnesi oluşturmak için kullanılabilen ReadableStream'lerle 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ıldığı anda bir akış yanıtı alır ve hizmet çalışanı ek veri enqueue() göndermeye devam ettiği sürece bu akıştan okumaya devam eder. Hizmet çalışanından sayfaya gönderilen yanıt gerçekten asenkrondur ve akışı doldurma üzerinde tam kontrole sahibiz.
Gerçek hayattan kullanım alanları
Önceki örnekte bazı yer tutucu /* your data here */ yorumları olduğunu ve gerçek uygulama ayrıntılarının az olduğunu fark etmişsinizdir.
Gerçek hayattan bir örnek nasıl olur?
Jake Archibald (şaşırtıcı olmayan bir şekilde) birden fazla önbelleğe alınmış HTML snippet'inden HTML yanıtı oluşturmak için akışları kullanmanın yanı sıra fetch() üzerinden aktarılan "canlı" verileri (bu durumda blog'unun içeriği) bir araya getirmeyle ilgili harika bir örneği paylaşıyor.
Jake'in de belirttiği gibi, akış yanıtı kullanmanın avantajı, tarayıcının blog içeriğinin tamamının getirilmesini beklemek zorunda kalmadan, önbellekten hızlıca yüklenen ilk bit de dahil olmak üzere HTML'yi akış halindeyken ayrıştırıp oluşturabilmesidir. Bu sayede tarayıcı, progresif HTML oluşturma özelliklerinden tam olarak yararlanabilir. Bazı resim ve video biçimleri gibi aşamalı olarak oluşturulabilen diğer kaynaklar da bu yaklaşımdan yararlanabilir.
Akışlar? Uygulama kabukları mı?
Web uygulamalarınızı desteklemek için hizmet işçilerini kullanmayla ilgili mevcut en iyi uygulamalar, uygulama kabuğu + dinamik içerik modeline odaklanır. Bu yaklaşım, web uygulamanızın "kabuk"unu (yapınızı ve düzeninizi görüntülemek için gereken minimum HTML, JavaScript ve CSS) agresif bir şekilde önbelleğe almanın ve ardından her bir sayfa için gereken dinamik içeriği istemci tarafı istek aracılığıyla yüklemenin temelini oluşturur.
Akışlar, uygulama kabuğu modeline alternatif bir yaklaşım sunar. Bu yaklaşımda, kullanıcı yeni bir sayfaya gittiğinde tarayıcıya daha kapsamlı bir HTML yanıtı aktarılır. Akışlı yanıt, önbelleğe alınmış kaynakları kullanabilir. Bu sayede, çevrimdışıyken bile ilk HTML parçasını hızlı bir şekilde sağlayabilir. Ancak bu yanıtlar, sunucu tarafından oluşturulan geleneksel yanıt gövdelerine daha çok benzer. Örneğin, web uygulamanız kısmi şablonları birleştirerek HTML'yi sunucu tarafında oluşturmaya yarayan bir içerik yönetim sistemi tarafından destekleniyorsa bu model doğrudan akış yanıtlarının kullanılmasına dönüşür. Bu durumda şablon oluşturma mantığı, sunucunuz yerine hizmet çalışanında kopyalanır. Aşağıdaki videoda gösterildiği gibi, bu kullanım alanında akışlı yanıtların sunduğu hız avantajı çarpıcı olabilir:
HTML yanıtının tamamının akış şeklinde sunmasının önemli avantajlarından biri, videodaki en hızlı alternatif olmasının nedenidir. İlk gezinme isteği sırasında oluşturulan HTML, tarayıcının akış şeklinde HTML ayrıştırıcısından tam olarak yararlanabilir. Sayfa yüklendikten sonra dokümana eklenen HTML parçaları (uygulama kabuğu modelinde yaygın olduğu gibi) bu optimizasyondan yararlanamaz.
Dolayısıyla, hizmet çalışanı uygulamanızın planlama aşamalarındaysanız hangi modeli benimsemeniz gerekir: aşamalı olarak oluşturulan akış yanıtları mı yoksa dinamik içerik için istemci tarafı istekle birlikte hafif bir kabuk mu? Yanıt, şaşırtıcı olmayan bir şekilde şu faktörlere bağlıdır: Bir içerik yönetim sistemine ve kısmi şablonlara dayalı mevcut bir uygulamanız olup olmadığına (avantaj: akış); aşamalı oluşturmadan yararlanacak tek ve büyük HTML yüklerinin olup olmadığına (avantaj: akış); web uygulamanızın tek sayfalı bir uygulama olarak modellenmesinin en iyi olup olmadığına (avantaj: uygulama kabuğu); ve şu anda birden fazla tarayıcının kararlı sürümlerinde desteklenen bir modele ihtiyacınız olup olmadığına (avantaj: uygulama kabuğu).
Henüz hizmet çalışanı destekli akış yanıtlarının çok erken dönemlerindeyiz. Farklı modellerin olgunlaşmasını ve özellikle de yaygın kullanım alanlarını otomatikleştirmek için daha fazla araç geliştirilmesini bekliyoruz.
Yayınları daha ayrıntılı inceleme
Kendi okunabilir akışlarınızı oluşturuyorsanız controller.enqueue() işlevini rastgele çağırmak yeterli veya verimli olmayabilir. Jake, kullanım alanınıza özel bir veri akışı oluşturmak için start(), pull() ve cancel() yöntemlerinin birlikte nasıl kullanılabileceği hakkında ayrıntılı bilgi veriyor.
Daha ayrıntılı bilgi edinmek isteyenler Akışlar spesifikasyonunu inceleyebilir.
Uyumluluk
Kaynak olarak ReadableStream kullanılarak bir hizmet çalışanı içinde Response nesnesi oluşturma desteği Chrome 52'de eklendi.
Firefox'un hizmet çalışanı uygulaması henüz ReadableStream tarafından desteklenen yanıtları desteklemiyor ancak Streams API desteği için takip edebileceğiniz alakalı bir izleme hatası var.
Edge'de ön ek içermeyen Streams API desteği ile genel hizmet çalışanı desteği ile ilgili ilerleme durumu Microsoft'un Platform durumu sayfasında izlenebilir.