Cloudflare Workers (Edge Worker) で Micro Frontends

今回、また Micro Frontends の構築を試みようと思います。構築パターンの内、サーバーサイド統合パターン、特にエッジサイド統合を試しました。 その内容を紹介します。サンプルコードは、下記に残しています。

GitHub - silverbirder/micro-frontends-sample-code-5

Contribute to silverbirder/micro-frontends-sample-code-5 development by creating an account on GitHub.

github.com

Edge Side Include (ESI)って

ESI Language Specification 1.0

www.w3.org

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 を下記のようなテンプレートで組み込むことができます。

GitHub - cloudflare/rustwasm-worker-template: A template for kick starting a Cloudflare Worker project using workers-rs. Write your Cloudflare Worker entirely in Rust!

A template for kick starting a Cloudflare Worker project using workers-rs. Write your Cloudflare Worker entirely in Rust! - cloudflare/rustwasm-worker-template

github.com

特定の重い処理を Rust の WebAssembly で処理するようなフラグメントをページに混ぜることができます。

構築して困ったこと

同一ドメイン内での Edge Workers 通信が不可

Cloudflare Workers は、任意のドメインで動かすことになります。 例えば、ドメイン A 内に複数の Cloudflare Workers X と Y があったとすると、 X から Y への通信ができないです。

そのため、複数の Cloudflare Workers を使用する場合は 複数のドメインが必要になります。 先程の例なら、ドメイン A に属する Cloudflare Workers X からドメイン B に属する Cloudflare Workers Y へ通信することができます。 私は、freenom の tk ドメイン(無料)を複数購入しました。

Freenom - A Name for Everyone

freenom.com

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

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

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

ngrok - All your traffic. One gateway. | API Gateway, Secure Tunnels, Traffic Management

ngrok is an all-in-one cloud networking platform that secures, transforms, and routes your traffic to services running anywhere.

ngrok.com

GitHub - localtunnel/localtunnel: expose yourself

expose yourself. Contribute to localtunnel/localtunnel development by creating an account on GitHub.

github.com

Cloudflare Workers による制約が大きい

Cloudflare のプラットフォーム上では、下記のランタイム API が使用できます。

Runtime APIs · Cloudflare Workers docs

The Workers runtime is designed to be JavaScript standards compliant and web-interoperable. Wherever possible, it uses web platform APIs, so that code can be reused across client and server, as well as across WinterCG JavaScript runtimes.

developers.cloudflare.com

Cloudflare Workers の仕組みを把握していないのですが、この提供されている API 以外は、 確か使えなかったような気がします。

最後に

Edge って、私の印象では、単なる静的コンテンツを置くだけのものと考えていました。 それが、動的なコンテンツ、つまり Edge Workers のような存在を知り、Edge の世界が広がったように感じます。 Web アプリケーションを、よりユーザーに近い Edge へ配置するようにすれば、レスポンス速度改善が期待できます。

Micro Frontends というより、Edge Workers の話が多かったですね。(笑)