Cloudflare Workersのようなサーバーレスなコンピューティングプラットフォームとしてここ数年活発な「エッジサーバーでプログラムを実行する環境」(呼び方が定まらないので一旦Edge Functionsとする)でアプリケーションを作る*1とブラウザが通信する先にもう1つブラウザが存在するような妙な感じを覚えていた。
例えばNext.jsのAPI Routesなら書いたコードはNode.jsで動くので頭をサーバーサイドモードにすればいいが、Cloudflare Workersで動くエンドポイントを書く時はそうでない…… おまえ、ブラウザなのか？ みたいな
でもよく考えたらこれらのプラットフォームはSpiderMonkeyやらV8やらのブラウザと同じJavaScriptエンジンを組み込んだ実行環境を持っていて、APIも環境の制限(TCP接続とかファイル読み書きとか)も似ているからそう感じても当然かと思った。
1年ぐらい前のThe Changelog PodcastでRyan Dahlが出演してDenoやDeno Deployについて語っていた回でDenoはブラウザのAPIとの互換性を持たせるデザイン意図を語っていた
And by the way, I should be explicit - Deno is trying not to have an API. Deno is trying to be the web browser API. Deno is trying to not have a specific Deno API, but just - if you want to encode a string into a uint array you use a text encoder. We don’t have a special Deno API for that. https://changelog.com/podcast/443#t=01:04:08.04
だからWeb Workersのようなメインスレッド以外で動いてドキュメントの描画には関与しない処理がたまたまリモートにあって、レスポンスを返してくる。と考えるようにした。
ブラウザの中のさらにその中のWeb APIの一部だろうという話はあるんだけど「Edge Functionはブラウザ」のがタイトルとしてカッコよかったのでいいじゃないですか。
開発者から見たメンタルモデルは上記とも言えるんだけどアプリケーションのユーザーからして見たら実行コンテキストは外部だし、取り扱うデータもすべてのユーザーを横断するものの可能性もあるしで若干ミスリードかもしれない。
ブラウザじゃなくてもEdge Functionsはフロントエンド領域だろうという例で、時雨堂 SaaSの技術スタック解説でCloudflare Workersはフロントエンドに分類されているというのもある
Web APIまわりの議論
最近特に"なんとかEdge Functions"がたくさんリリースされているように見えるのはDeno Deployの仕組みを他社(SupabaseやNetlifyのこと)に提供する拡大戦略が背景にあるようだ。
https://deno.com/deploy/docs/subhosting
Node.jsやDenoでブラウザと汎用プログラミング環境用のAPI互換性を上げることの是非についても議論があり、以下を読んだ
yosuke-furukawa.hatenablog.com
Edge Functionsのような環境でブラウザ向けのコードを取り込もとしている時流があると思うので関連しそうだ。
一方Cloudflare WorkersではNode.jsのランタイムにあるAPIを独自に互換性を持たせるような動きもあって、これは逆のアプローチだなと思う。
Edge Functionsでアプリケーションを作ることを中心に考えると、VercelなどはNext.jsでがっつりNode.jsのAPIに依存しているからこっちのが都合が良さそうで、Remix陣営は後発の利でいろんなPaaS向けのアダプタをサポートする用にデザインされており(間も無くDeno Deployも使えるようになる)そんなに恩恵はなさそう。
*1:Edge Functionsで動くアプリケーション: https://github.com/laiso/isucholar_cfworkers とか
