Cloudflare WorkersでSSRができると何が嬉しいか

Next.jsの対抗馬となりそうなReactのフレームワークでRemixのv1.0がリリースされました。

https://remix.run/

個人的にRemixでいちばん魅力を感じているのはCloudflare WorkersでSSRができるという点です（現状ではNext.jsをCloudflare Workers上でSSRするのは難しい）。これがなぜ嬉しいのかと言うと、パフォーマンスを出しつつ、低コストで運用でき、大量のアクセスに対しても低コストでスケールできそうだからです。

そもそもSSRをする必要ある？

ほとんどのWebサービスはSSRなしでSPAとしてビルドし、Cloudflare PagesやGitHub Pagesに静的ファイルをのせて動かせば十分だと思います。

例えば僕が先日作った個人開発のサービスもReact on Cloudflare Pagesの完全なSPAですが、SSRが必要な要素はまったくありません。

https://zenn.dev/catnose99/articles/eb0e7a51876920

更新頻度が少ないブログのようなものであれば、その都度ビルドするJAMstackの構成で良いと思います。
ただ、ユーザーが投稿できるWebサービスで、ページごとにOGPの設定を切り替えたり、SEO対策を突き詰めたりしたいといったときにはSSRをしたくなることがあります。

そのような「なんやかんやでSSRしたい」そして「SSRのパフォーマンスも意識したい」「コストも抑えたい」というときの選択肢としてRemix on Cloudflare Workersはとても魅力的だと思います。

以下で詳しく書いていきます。

1. コールドスタートを抑えるために必要なコストを削減できる

自分は個人開発でいろいろとサービスを作るのが好きなのですが、サービスの構成を考えるときに最も気にかけるのがコスト面です。

個人開発あるあるですが、リリース後にあまり使ってもらえなかったとき、アクティブに開発はしないもののサービスは継続して提供する（つまり放置）ということになりがちです。このようなケースのために、ランニングコストは抑えつつアクセスがあればスムーズにサービスを提供できる形にしておくのがベストです。

例えばアクセスが少ないアプリケーションをHerokuの無料プランで動かす場合、リクエストを受けてからインスタンスが起動し、その結果レスポンスが遅くなる、といった問題にハマったりします。定期実行でリクエストを送ることでスリープモードに入らせないといったテクニックもありますが、設定が面倒ですし、そのぶんだけ無料枠が削られてしまいます。

Cloudflarew Workersでは、公式ブログ（Eliminating cold starts with Cloudflare Workers）に書かれているようにコールドスタートがありません。

1日に10回しかアクセスがないサービスでもコールドスタートによる心配する必要がないというわけです。

2. スケールしてもコストが削減できる

Cloudflare Workersは料金がかなり良心的です。

無料プランでも10万リクエスト/日まで無料で使用できます。実装によりますが、ユーザーが1回サービスにアクセスしたときに1〜3回Workersが走る程度であれば、無料でも相当な数のアクセスを捌くことができると思います。

個人開発者は「流行るか分からないしマネタイズは後回しでとりあえずリリースしちゃおう」みたいなことをやりがちです。そして、ごく稀に想像していた100倍以上アクセスがあるといったことが起きます。だいたいのケースではこのようになりませんが、このような「想像の100倍使われてる〜〜〜」という夢を見て、個人開発をする人は多いと思います。

思ったより使われちゃったパターンに遭遇したときにもCloudflare Workersをメインで（適切に）使っていれば、きっとクラウド破産は避けられると思います。

3. キャッシュが柔軟にやりやすい

Cloudflare WorkersではKVというキーバリューストアの機能を簡単に使用できます。KVでは最大25MBまでの値を高速で読み書きができ、一時的にキャッシュしておきたいHTTPレスポンスや、消えてしまっても構わないようなデータを格納する用途で使うことも可能です。

エッジでSSRをしても外部APIからデータをフェッチしていてはパフォーマンスのメリットは薄れてしまいますが、KVにデータを格納することでAPIリクエストの頻度を減らせるケースもありそうです。

Cloudflare Workers + Remix + Supabase は個人開発ではかなり良さそう

Cloudflare Wokersのドキュメントでは（JavaScriptクライアント経由で）SupabaseのPostgreSQLにアクセスする例が紹介されています。

Build data-driven applications with Workers and PostgreSQL

WorkersとSupabaseの組み合わせは低コストでちょっとしたWebサービスを作るには有力な選択肢になりそうです。

Workersでアプリケーションを動かして、SupabaseのPostgreSQLでデータを永続化して、Supabase Authでログイン機能をつけて…というイメージです。PostgreSQLへのアクセスが遅ければクエリの結果をKVにキャッシュすることもできます。

Cloudflare Workersでフルスタックなアプリケーションを動かすときに気をつけた方が良さそうなこと

さて、ここまで良い話ばかりを書いてきましたが、ひとつ大きな懸念点があります。それはCloudflare Workersの厳しい制限です。

https://zenn.dev/catnose99/articles/d1d16e11e7c6d0

中でも「scriptのサイズは1MBが上限 ^[1]」といった点については、サイズの大きいライブラリを使ったり、中〜大規模なアプリを作る中でどうしても超えてしまうかもしれません。例えばfirebase-adminはサイズが結構大きいのですが、Workers上でも使えるのか疑問です（誰か試した人がいれば教えてください）。

個人開発のサービスであっても、リリース後もガンガン機能をつけていきたいのであればCloudflare Workersではすぐに限界がきて移行を強いられるかもしれません。

現時点では「機能が少なくやることは単純だけど大量のアクセスがあるかもしれない」というサービスを作るときに上で挙げたような構成を検討するのが良いかと思います。

（仮に自分がZennのようなサービスを1から作るとしたら、Remix on Cloudflare Workersというスタックにはしないと思います）

脚注

1. 今後上限が上がりそうです（下のコメント欄を参照） ↩︎