【ITニュース解説】How Workerify's Vite Plugin and Core Library Work Together: A Deep Dive

Service Workerは、ウェブサイトがバックグラウンドで動作し、ネットワークリクエストを制御したり、オフライン機能を可能にしたりする特別なJavaScriptスクリプトである。しかし、このService Workerを扱うのは複雑なことが多い。Workerifyは、このService Workerの複雑な側面すべてを単純化するのではなく、ブラウザ内で直接APIのようなエンドポイントを簡単に作成できるようにすることを目指しているツールだ。具体的には、ウェブアプリケーションのバックエンドAPIと似たルーティングの仕組みを、Service Worker内で完全に動作するように提供することで、ブラウザ内で直接データ処理やリクエスト応答を行えるようにする。これにより、ネットワークを介さずに、まるでAPIを呼び出すかのようにブラウザ内部で処理が完結し、高速なレスポンスが期待できる。

Workerifyは主に二つのパッケージで構成されている。一つは@workerify/libというコアライブラリで、これはアプリケーション側でルート（特定のURLパスに対応する処理）を定義し、そのリクエストのマッチングと処理を行う役割を担う。もう一つは@workerify/vite-pluginというViteプラグインで、こちらはService Workerの登録を管理したり、開発環境や本番環境でのビルド時に必要な最適化を行ったりする。これら二つのパッケージは、BroadcastChannel APIというブラウザの機能を使って互いに通信する。BroadcastChannel APIは、同じオリジン（ウェブサイト）内の異なるブラウジングコンテキスト（例えば、タブやウィンドウ、Service Workerなど）間でメッセージをやり取りするための仕組みだ。これにより、アプリケーションが定義したルート情報をService Workerに渡し、Service Workerがネットワークトラフィックを傍受して、適切なアプリケーションの処理に引き渡すことが可能になる。

Workerifyにおけるリクエストの流れは、次のステップで進行する。まず、開発者がプロジェクトにWorkerifyのViteプラグインを導入すると、プラグインはいくつかの重要な処理を行う。具体的には、workerify-sw.jsというService Workerファイルを生成し、Service Workerを簡単に登録するための仮想モジュール（virtual:workerify-register）を提供する。開発モードではこのファイルはメモリ上から提供され、高速な開発体験を、本番ビルド時には実際のビルド資産として出力される。次に、アプリケーションのコードでは、この仮想モジュールを使ってService Workerを登録し、@workerify/libを使ってWorkerifyのインスタンスを生成する。このインスタンスに対して、Fastifyのような使い慣れた記法で、特定のURLパス（例: /todos）に対するGETやPOSTなどのリクエストを処理する関数（ハンドラ）を定義する。例えば、/todosへのGETリクエストが来たら保存されているTodoリストを返す、POSTリクエストが来たら新しいTodoを追加するといった処理だ。そして、app.listen()を呼び出すことで、Service Workerとの連携が開始される。

app.listen()が実行されると、アプリケーションはユニークな識別子（コンシューマID）を生成し、これをService Workerに登録する。この登録の際に、アプリケーションで定義されたすべてのルート情報もBroadcastChannelを通じてService Workerに送信される。Service Workerはこのルート情報を受け取ると、どのコンシューマIDがどのルートを処理すべきかを認識する。 アプリケーションがウェブページを表示している間、ユーザーが何らかの操作（例えば、/todosへのリクエスト）を行うと、Service Workerがネットワークリクエストを傍受する。Service Workerは、受け取ったリクエストのURLが登録されているルートと一致するかどうかを確認する。もし一致するルートが見つかれば、Service Workerはそのリクエストの詳細を、BroadcastChannelを通じて対応するコンシューマ（つまり、リクエストを処理すべきアプリケーションのインスタンス）に送信する。リクエストを受け取ったアプリケーションのインスタンスは、事前に定義されたハンドラ関数を実行してリクエストを処理する。処理が完了すると、その結果（ステータスコード、ヘッダ、ボディなど）は再びBroadcastChannelを通じてService Workerに返される。最後に、Service Workerはその応答をブラウザに渡し、ブラウザがユーザーに結果を表示する。

Workerifyは、ウェブアプリケーションが複数のタブで開かれている状況でも適切に動作するよう設計されている。Service Workerはブラウザのすべてのタブで共有されるため、複数のタブから同じルートに対するリクエストがあった場合に競合が発生しないよう、Workerifyは各タブに独自のコンシューマIDとルートのセットを与えることで分離を保証する。これにより、あるタブで定義されたルートが別のタブの処理に影響を与えることはない。また、タブが閉じられた際には、そのタブに関連するルート情報もService Workerから自動的にクリーンアップされるため、メモリの無駄遣いを防ぎ、不要なルートが残ることもない。

WorkerifyがBroadcastChannel上でやり取りする通信には、シンプルなプロトコルが定義されている。例えば、ルートをService Workerに登録する際には、workerify:routes:updateというtypeのメッセージと共に、コンシューマIDと定義されたルート情報が送信される。Service Workerがリクエストを処理するためにアプリケーションに送る際には、workerify:handleというtypeのメッセージと、リクエストID、コンシューマID、リクエストの詳細が送られる。アプリケーションが処理結果をService Workerに返す際には、workerify:responseというtypeのメッセージと、リクエストID、ステータス、ヘッダ、ボディが送られる。このような明確なプロトコルによって、異なるコンテキスト間の信頼性の高い通信が実現されている。

Viteプラグインは、開発と本番環境の両方で、プロジェクトのパフォーマンスと開発体験を向上させるためのビルド時最適化も提供する。Service Workerのテンプレートは事前にコンパイルされ、効率的に動作するようになっている。また、先述のService Worker登録コードを生成する仮想モジュールにより、開発者は複雑な登録処理を意識することなく利用できる。さらに、アプリケーションのベースパスが自動的に処理されるため、デプロイ環境の違いによる設定変更の手間も省ける。開発モードでは、Service Workerのファイルがメモリから提供されるため、変更が即座に反映され、開発中のService Workerの再インストールによる手間が軽減され、ホットリロードがスムーズに行われる。

このWorkerifyのアーキテクチャは、従来のService Worker開発におけるいくつかの課題を解決し、多くの利点をもたらす。開発者はFastifyのような使い慣れたAPIを使って、Service Worker内部で動作するAPIライクなエンドポイントを定義できるため、学習コストが低い。リクエストがブラウザ内部で処理されるため、ネットワークを介した遅延がゼロになり、非常に高速なレスポンスタイムを実現できる。これは、シングルページアプリケーション（SPA）や、HTMXのようなサーバーサイドレンダリングと連携する技術との相性が良い。開発体験も非常にスムーズで、ホットリロード中にService Workerを再インストールすることなくルートの変更が反映される。また、TypeScriptが完全にサポートされているため、型安全なコード開発が可能だ。

パフォーマンス面では、BroadcastChannelのオーバーヘッドは最小限に抑えられている。ルートのマッチングは、リクエストが発生したときに初めて行われる「遅延マッチング」を採用しているため、常にすべてのルートをチェックする必要がなく、効率的である。閉じられたタブに関連するルートは自動的にクリーンアップされるため、無駄なリソース消費がない。さらに、Service Workerが一元的にすべてのルート情報を保持するため、各タブが個別にルートを持つよりもメモリ効率が良い。

具体的な利用例として、シンプルなTodoアプリを考えてみよう。アプリケーションコード内で@workerify/libを使ってインスタンスを生成し、/todosへのGETリクエストで既存のTodoリストをHTML形式で返すハンドラや、/todosへのPOSTリクエストで新しいTodoを追加し、特定のヘッダを設定するハンドラを定義できる。これにより、ウェブページ上からHTMXのような技術を使って/todosにリクエストを送ると、そのリクエストはService Workerによって傍受され、ブラウザ内部で定義されたWorkerifyのハンドラが実行され、結果がページに反映される。ネットワークリクエストを発生させることなく、ユーザーインターフェースが更新されるのだ。

Workerifyを始めるのは非常に簡単である。npx @workerify/create-htmx-appというコマンドを実行するだけで、Vite、HTMX、Workerifyが組み込まれたプロジェクトのひな形がすぐに生成され、すぐに実験を開始できる。

結論として、WorkerifyはService Workerを使ったルーティングを強力かつシンプルにするツールである。アプリケーションでのルート定義（コアライブラリ）とService Workerの管理（Viteプラグイン）を分離し、BroadcastChannelを使って高速な通信を実現している。また、マルチタブ環境での分離を自動的に処理し、開発者には使い慣れたAPIを提供することで、学習コストを低く抑えている。この設計は、オフラインファーストのアプリケーションや、ゼロ遅延のSPA、さらにはHTMXのような技術と組み合わせた新しいクライアントサイドアーキテクチャの可能性を広げるものだ。Workerifyはまだ発展途上のツールだが、Service Workerを新しい方法で試すための有用な出発点となり、特にHTMXのようなシンプルなアプリケーションモデルへの移行を促進する可能性も秘めている。