イベント駆動型サービス実行基盤としての Service Worker - Qiita

当初は better AppCache1 として開発が始まった Service Worker2 ですが、ページとは独立したライフサイクルを持つことでイベント駆動型のサービス3実行基盤としての色合いが強くなっています。本記事では、イベント駆動型のサービス実行基盤とは何なのか、そこへと発展していった流れについて紹介します。 なお本記事は Service Worker の使い方を紹介するものではありません。Service Worker をある程度理解している開発者を想定読者としています。また、本記事はすべて私の個人的な意見や調査に基づくものであり、所属する組織、団体とは一切関係ありません。前置きおわり。 AppCache、そして Service Worker へ 冒頭でも述べた通り、Service Worker は当初 better AppCache として開発が始まりました4 5 6。AppC

[efcl]

Better AppCacheから始まったService Workerが、ページに依存しない生存期間へ変化していき、fetch以外のイベントもハンドリングできる基盤となっていった変遷について。

[t2wave]

“「ブラウザの挙動を再定義し、プリミティブを提供していく」という Extensible Web 的な考え”

[geta6]

良記事だった

[kitokitoki]

○ "イベント駆動型サービス実行基盤としての Service Worker" 良記事

[nekoruri]

もうこれがサーバレスアーキテクチャでいいよｗ

[braitom]

Service Workerがどういった過程、目的で進化してきたかが書かれている。イベント駆動型のサービス実行基盤でありイベントハンドラとして、onfetch、onpush、onsyncがある。分かりやすい。

[tofu-kun]

分かりやすい

[Jxck]

「もう一つのプロセス」としての Service Worker の話