Cloudflare Workers (Edge Worker) で Micro Frontends
今回、また Micro Frontends の構築を試みようと思います。構築パターンの内、サーバーサイド統合パターン、特にエッジサイド統合を試しました。 その内容を紹介します。サンプルコードは、下記に残しています。
https://github.com/silverbirder/micro-frontends-sample-code-5/
Edge Side Include (ESI)って？
https://www.w3.org/TR/esi-lang/
ESI は、SSI と似たようなもので、サーバーサイド側でコンテンツを挿入する仕組みの 1 つです。ESI の場合、挿入するコンテンツ(ページフラグメント)が Edge 側にあると理解しています。 そのため、Edge キャッシュをコンテンツ毎に効かせれるメリットがあります。 現状、ESI 言語仕様は W3C へ提出していますが、承認が降りていない状況です。Akamai などの CDN 企業や、Varnish などのキャッシュプロキシサーバは、ESI を一部実装しています。
個人で試すのに、Akamai は金銭的に厳しいですし、varnish の VCL を記述したくない(好き嫌い)です。 そこで、Edge Worker と呼ばれる仕組みを試そうと思います。
次の引用は Akamai ブログからです。
EdgeWorkers は、世界中に分散配置された Akamai の Edge サーバー上で、カスタムしたプログラムコードを実行できるようになる新しいサービスです
※ https://blogs.akamai.com/jp/2019/10/edgeworker.html
要は、Edge Workers とは CDN が提供するプラットフォーム上で、プログラムコード、例えば Javascript などが実行できるサービスです。
Edge Workers
個人で使える Edge Workers だと、fly.ioやCloudflare Workers があります。後者の Cloudflare Workers には、HTMLRewriter という HTML を書き換える機能があり、Micro Frontends に使えそうだったため、今回は Cloudflare Workers を使用します。
構成
次のような構成を考えてみました。
※ PodiumとAra-Framework に影響されています。
※ draw.ioの sketch style で書きました。
それぞれのブロックが Cloud Workers となります。
簡単に、図の左から右の順に説明していきます。 Router で、Web アプリケーションのルーティングを管理します。 ルーティングでは、HTTP リクエストの内容に基づいて、どのページか振り分けます。 振り分けられたページでは、後述するフラグメントを含めて HTML を構築します。 その HTML を HTMLRewiter で処理し、Proxy に存在するフラグメントがあれば、フラグメントの HTML へ置換されます。 フラグメントでは、HTML,CSS,JS を取得する PATH を JSON 形式で返却するようにします。 JSON を返す URL は、/manifest.json と統一しています。
このような構成を取ることで、担当領域を分割することができます。 例えば、フラグメント A とページ X をチーム 1 が管理し、フラグメント B、C、ページ Y をチーム 2 が管理するなどです。
また、Rust の WebAssembly を下記のようなテンプレートで組み込むことができます。
https://github.com/cloudflare/rustwasm-worker-template
特定の重い処理を Rust の WebAssembly で処理するようなフラグメントをページに混ぜることができます。
構築して困ったこと
同一ドメイン内での Edge Workers 通信が不可
Cloudflare Workers は、任意のドメインで動かすことになります。 例えば、ドメイン A 内に複数の Cloudflare Workers X と Y があったとすると、 X から Y への通信ができないです。
https://community.cloudflare.com/t/issue-with-worker-to-worker-https-request/94472/37
そのため、複数の Cloudflare Workers を使用する場合は 複数のドメインが必要になります。 先程の例なら、ドメイン A に属する Cloudflare Workers X からドメイン B に属する Cloudflare Workers Y へ通信することができます。 私は、freenom の tk ドメイン(無料)を複数購入しました。
直接 IP アドレスへリクエストできない
ローカル開発時に困ったことがあります。 Cloudflare Workers をローカル開発する場合、wrangler:dev というコマンドで検証します。 検証中に、他の Cloudflare Workers の URL(localhost:XXXX)へアクセスしようとしても、直接 IP となるため失敗します。
そのため、下記のようなサービスを使って、私は解決させました。
https://github.com/localtunnel/localtunnel
Cloudflare Workers による制約が大きい
Cloudflare のプラットフォーム上では、下記のランタイム API が使用できます。
https://developers.cloudflare.com/workers/runtime-apis
Cloudflare Workers の仕組みを把握していないのですが、この提供されている API 以外は、 確か使えなかったような気がします。
最後に
Edge って、私の印象では、単なる静的コンテンツを置くだけのものと考えていました。 それが、動的なコンテンツ、つまり Edge Workers のような存在を知り、Edge の世界が広がったように感じます。 Web アプリケーションを、よりユーザーに近い Edge へ配置するようにすれば、レスポンス速度改善が期待できます。
Micro Frontends というより、Edge Workers の話が多かったですね。(笑)