Cloudflare Workers (Edge Workers) で Micro Frontends

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

github.com

Edge Side Include (ESI)って?

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.ioCloudflare Workers があります。後者のCloudflare Workersには、HTMLRewriter というHTMLを書き換える機能があり、Micro Frontendsに使えそうだったため、今回はCloudflare Workersを使用します。

構成

次のような構成を考えてみました。

Cloudflare Workers + Micro Frontends

PodiumAra-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.com

特定の重い処理を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/37community.cloudflare.com

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

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#error1003support.cloudflare.com

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

ngrok.com github.com

Cloudflare Workersによる制約が大きい

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

developers.cloudflare.com

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

最後に

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

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