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 ドメイン(無料)を複数購入しました。

https://freenom.com/

直接 IP アドレスへリクエストできない

ローカル開発時に困ったことがあります。 Cloudflare Workers をローカル開発する場合、wrangler:dev というコマンドで検証します。検証中に、他の Cloudflare Workers の URL(localhost:XXXX)へアクセスしようとしても、直接 IP となるため失敗します。

https://support.cloudflare.com/hc/ja/articles/360029779472-Cloudflare-1XX-%E3%82%A8%E3%83%A9%E3%83%BC%E3%81%AE%E3%83%88%E3%83%A9%E3%83%96%E3%83%AB%E3%82%B7%E3%83%A5%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0#error1003

そのため、下記のようなサービスを使って、私は解決させました。

https://ngrok.com/

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 の話が多かったですね。(笑)