API が重い…と悩む僕を救った Hono と Cloudflare

「なんだか、最近レスポンスがもっさりしてるな…」

自分の作った個人開発アプリを触っていたとき、ふと指が止まった。最初は気のせいかと思った。けれど、一度気になり始めると、もうダメだ。 API からの応答が返ってくるまでの、あのコンマ数秒の「間」が、ひどく気になる。

フリーランスとしてクライアントワークの合間に、自分の情熱を注いで作っている小さなサービス。ユーザーはまだ数えるほどしかいない。それなのに、この遅さ。これからユーザーが増えたら、一体どうなってしまうんだろう——。

かつての僕が作っていた API は、多くの人がそうであるように、Node.js と Express で書かれていた。 VPS（仮想専用サーバー）を借りて、そこで動かす。いわば「伝統的な」構成だ。悪くはない。むしろ、長年の知見が詰まった安定の選択肢のはずだった。

でも、僕が作りたかったのは、もっと手軽で、もっと速い、小さな API。そのために、Express は少し「重厚長大」に感じられた。ルーター、ミドルウェア、エラーハンドリング…便利な機能たちも、今回の僕の用途にはオーバースペックに思えた。

Next.js の API ルートも考えた。でも、フロントエンドと密結合したあの環境は、純粋な API サーバーとしては、やはり少し違う気がした。

もっとこう、Tシャツに短パンで出かけるような、気軽さはないものか。ジャケットと革靴を求められるような場所じゃなくて。

そんなモヤモヤを抱えながら、僕は新しいフレームワークを探す旅に出た。

僕の前に現れた 「Hono」 という名の光

そんなとき、SNS のタイムラインで偶然、その名前を見つけた。

Hono (炎)

日本語の「炎」から名付けられたというそのフレームワークは、驚くほど僕の理想に近かった。

特に僕の心を掴んだのは、「Web 標準準拠」という思想だった。特定のフレームワークの「お作法」を覚えるのではなく、普遍的な知識が活かせる。これは、長く続く技術の旅路において、確かな道標になる、と直感した。

Cloudflare Workers との出会い

そして、Hono のドキュメントを読み進めるうちに、僕はもうひとつの運命的な出会いを果たす。 Cloudflare Workers だ。

サーバーを借りて、OS のアップデートを気にして、Node.js のバージョンを管理する…そんなインフラ管理の煩わしさから、僕たち開発者を解放してくれる。しかも、ユーザーに最も近い場所（Edge）でコードが動くから、物理的な距離の制約を受けにくく、応答がとにかく速い。

「Hono の軽量さ」と「Cloudflare Workers の速さ」。このふたつが組み合わさったら、一体どうなってしまうんだろう？

僕はいてもたってもいられず、早速試してみることにした。