ServiceWorker
UI Threadとは別のThreadで動作するJavaScript環境
これを応用して、以下のような用途に使える
Proxy ServerとCache操作
client ↔ ServiceWorker ↔ server
client/server間でやり取りされるreq/resを操作したり
serverの代わりにcacheから返すようにすることでoffline作業できるようにしたり
performanceの向上
UIと別のthreadを使うので、重い処理を任すことでperfomance向上に繋がる
参考
ざっくり概要
>#WIP
呼び出したら、タスクが終わるまでは終了しない
強制終了はできない
browserを閉じた後も動作する
まじ？
できないこと
DOMを操作することはできない
window 、 document へのアクセスはできない状態の保持
Service Worker はブラウザによって不要になったら破棄される
HTTP通信
HTTPS通信のみの利用ができるという意味
localhostは例外的に利用可能
ネットワーク通信をするときに、
そのやり取りする相手を
サーバーなのか
キャッシュなのか
などを制御できる
普通に通信していると見せかけてキャッシュを見ている的な
windowを閉じたあとでも、起動し続けることもできる
なにができる
キャッシュをいじる
キャッシュする処理
fetch eventの仲介人になる
サーバーから取る代わりにキャッシュから取得する処理
ページからのリクエストをプロキシ
Proxy Serverになる
client ↔ ServiceWorker ↔ server
MSWとかがこれをやっている
ブラウザウィンドウが閉じていても動かせることができるので。
ブラウザウィンドウとは何を指している？
そのサイトを見ていなくても、Chromeアプリが「起動」してればおｋってことか？
いや、プッシュ通知のイメージ的には、アプリは起動していなくてもおｋか
つまり、ブラウザがどうこうというよりは、OSがどうこうという技術なのか？
バッググラウンド同期
ユーザーがオフライン状態で、「ファイルをアップロード」操作をしたら、次にオンラインになったときにその操作を実際にやる
ページとの間でイベントハンドラを使ってのメッセージ送受信
Cacheの保存先の例
ライフサイクル
状態
parsed
初期状態。SWのインストールすらされていない
installing
インストール中
installed
インストール成功後の状態
SWはまだ有効になっていない
activating
有効になった状態
activated
fetch/messageイベントの待機状態
redundant
無効になった状態
参考
offline cookbook
2つのcacheの方針
事前に、必要そうなassetsをcacheする
ServiceWorkerのinstall時に行われる
ユーザーの操作中にreqesutして得られたassetsを随時cacheする
用途
どういう仕組み？
どこに実装されているもの？
ブラウザ？OS？
ブラウザにおけるJavaScript Engineの位置づけを理解していないと理解できない気が
なにかつくる
Scrapbox
参考
くわしすぎる
わかりやっすい