nest: coi-serviceworkerを読む会
okuoku純粋にWebAssemblyアプリをホストするだけならservice workerを挟む必要性は無いが、そもそも論としてWebAssemblyでSharedArrayBufferを使うためにはCOEPのヘッダを足す必要はあるので coi-serviceworker が何をやっているのか見てみることにした。
例えばHonoはService Workerでも動くので、前書いたHTTP経由のWebRTCセッションと組み合わせてWebアプリ自体もリモートに置ける気がする(Service Worker内のHonoでルーティングをして、リモート側のアプリはmiddlewareとしてマウントする)が、純粋なSPAじゃないとダメってのがかなり制約になる。例えばJenkinsとかそのままリモート化できると便利なんだけど。。
okuoku全体構造
typeof window === 'undefined' かどうかで、Service WorkerなのかWebページなのかを識別している。原理的には別々のスクリプトでも良いけど、自分自身のパスを簡単に調べられるんだから同じスクリプトにするのが賢いよな。。
okuokuService Worker側
単に "fetch" イベントのリクエストを fetch し、ヘッダを加工しているだけ。そのまま渡して良いのか。。
エラーはバブルしていない。 ...良いのか。。？
status がゼロになるのは no-cors して opaque なレスポンスを受けた場合。これは自分のユースケースには無いはず。。Service Workerではこのresponseオブジェクトの中身を触れないので、単にそのまま返却することになる。
okuokuWebページ側
Webページ側は他のスクリプトに影響しないように、コードをfunctionで包んでいる(IIFE https://developer.mozilla.org/ja/docs/Glossary/IIFE )。
デフォルトのリロード関数。
自分にservice workerが居るかをチェックする。
window.document.currentScript.src で自分自身をregisterする。
どういう異常ケースをハンドルしたいのかが読み取れないな。。 sessionStorage に値を入れてロード時に読んでいる。