Luke Edwards氏は、先日のSvelte Summit 2020で講演し、エッジでのSvelteアプリケーション運用について論じた。講演の中で氏は、Cloudflare WorkersとGoogle Cloudを使って簡単なSvelteアプリケーションを構築し、実行するデモを公開した。
最初にEdwards氏は、Web WorkerとService Workerについて説明した。Web Workers APIを使用すれば、バックグラウンドスレッドを使って、メインスレッドとは独立したスクリプトの実行が可能になる。Web WorkerはCPU能力を必要とする計算処理を、メインスレッドをブロックすることなく実行するために使用されることが多い。メインスレッドはイベントループを実行しており、その中でユーザのインタラクションが処理される。メインスレッドがブロックされると、従って、ユーザ入力への応答性に悪影響があるのだ。Web Workerは計算処理を並行して実行する場合にも使用され、マルチコアアーキテクチャであれば並列的に実行される可能性がある。
Workerそれ自体が新たなWorkerを起動することも可能である。起動されたWorkerは、同じoriginを親ページとしてホストされる。Workerはただし、その設計上、オペレーションに制限がある。WorkerからDOMを更新することはできない。これはDOM状態への並行アクセスの危険性を回避するためだ。同じ理由で、windowオブジェクトのデフォルトメソッドやプロパティの一部も使用できない。
Workerは独立したスレッドやスコープを持っているが、通信を行うためのメッセージ処理はメインスレッドに依存している。postMessage()メソッドを使ってメッセージを送信し、onmessageイベントハンドラを通じてメッセージに応答するのは、どちらも同じだ。メッセージのデータは共有ではなく、コピーされる。worker.jsファイルに含まれるコードを実行するWeb Workerは、メインスレッドから次のように生成することが可能である。
/* main.js */
const myWorker = new Worker('worker.js');
Service Workerはブラウザとネットワーク、および/またはキャッシュ間のプロキシになるという、明確な目的を持つWorkerである。
(出典: https://bitsofco.de/)
Service Worker APIは、そのプロキシとしての役割を果たすために必要な機能をService Workerに提供する。インストールされ、アクティベートされたService Workerは、mainドキュメントの生成する任意のネットワーク要求をインターセプトすることができる。独自のストレージキャッシュをコントロールすることも可能である。fetch要求をインターセプトするService Workerの実装例を以下に示す。
/* service-worker.js */
self.addEventListener('fetch', function(event) {
// Return data from cache
event.respondWith(
caches.match(event.request);
);
});
次にEdwards氏は、Cloudflare Workerについて、形を変えたService Workerである、と説明した。
Cloudflare Workerはまったく同じもの、文字通り、まったく同じものです。同じWorkerインターフェースを使用し、Cloudflareネットワーク上の同じ場所に位置します。つまり、違いは物理的な配置位置のみなのです。クライアントとネットワークとコントローラキャッシュの間をプロキシするのも同じです。
ユーザマシン上に位置するService Workerと違い、Cloudflare Workerからローカルファイルシステムにアクセスすることはできない。Cloudflare Workerは、世界中の200を越えるロケーションに分散する、Cloudflareのマシン上にデプロイされるのだ。しかしながら、SvelteのSapperやNext.jsなどのアプリケーションフレームワークでは、アプリケーションのルートをページを実装したファイルにマップするために、ファイルベースのルーティングを使用している。
この制限を回避する手段としてEdwards氏は、サードパーティのクライアントバンドルホスティングを使用した。デモの例では、Svelteアプリケーションはローカルにビルドされて、Google Cloud Storageが処理するバケットにアップロードされている。Edwards氏の公開したCloudflare Workerの実装では、ローカルファイル名に代えて、クラウドストレージサービスの提供するURLを使用している。
Edwards氏は、デモで採用したアプローチのメリットとして、静的サイトのみに対応可能なCloudflare Worker Sitesを使用する場合に比較して、柔軟性があり、開発者によるコントロールの余地が大きい点を挙げた。バケットはデモのアーキテクチャとは分離されたコンポーネントであるため、アセットをアップロードする場合でもWorkerを再デプロイする必要はない。
費用もコントロール可能でなければならない、とEdwards氏は付け加えた。
バケットは実質的に無料です。ご存じのようにバケットからのデータ出力は極めて安価である上に、このアプローチであれば、課金は1回のみで済みます。
考えられるデメリットとして、Edwards氏は、新たな管理作業の発生(ルートロジックの定義とアプリケーション構築、2つの独立したデプロイユニットの管理、必要時の同期処理、キャッシュのパージなど)を挙げた。
Edwards氏の講演では2つのデモと、それらに関する多くの技術的説明が行われた。デモのソースコードはオンラインで公開されている。読者には、講演全体を確認するように推奨する。
Svelte SummitはSvelteに関する仮想カンファレンスである。2020年版は10月、オンラインで開催された。行われた講演のすべてが、Svelte SocietyのYouTubeチャネルで公開されている。