HonoはExpressの精神的後継として急速に普及している
HonoはTypeScript製の軽量Webフレームワークで、Cloudflare Workers発・現在ではNode.js/Bun/Deno/Vercel Edge/AWS Lambdaまで動くマルチランタイム対応が特徴です。Expressに近いミドルウェアAPIを保ちつつ、Web標準のRequest/Responseベース・型安全RPCサポート（Hono Client）など、モダンTSアプリ開発に必要な要素を揃えています。Express自体の開発が2024年に再開されたものの、エッジ対応がない点でHonoが優位な領域が広がっています。
Hono採用を検討すべき5つのシグナル
- Express/Fastifyで書いたAPIをエッジ環境で動かしたい
- サーバーレス環境でコールドスタートを最小化したい
- フロントとAPIの型を共有してEnd-to-End型安全を実現したい
- マルチランタイム（Node/Bun/Workers）で同じコードを動かしたい
- tRPCより素直なREST APIを書きつつ型安全性が欲しい
Express/Fastify/Nest.jsとの実務比較
Express: エコシステム最大・古いミドルウェア大量。エッジ非対応。
Fastify: 高性能・スキーマバリデーション内蔵。プラグインエコシステムも厚い。
NestJS: 大規模アプリ向け・依存性注入・デコレータベース。学習コスト大。
Hono: 軽量・マルチランタイム・型安全RPC・Webスタンダード準拠。中小規模に最適。
Hono Clientの威力
Honoの最大の差別化要因はhono/client。サーバ側のルート定義から型を抽出し、フロント側でclient.api.users.$post({ json: { name: 'x' } })のように完全に型安全に呼び出せます。tRPCのようなRPC体験をREST APIで実現できる点が、フルスタックTS開発の生産性を一段引き上げます。
実装の基本パターン
(1) ルート定義: app.get('/users/:id', (c) => c.json({ id: c.req.param('id') }))
(2) Zodバリデーション: @hono/zod-validatorでリクエストを型安全に検証
(3) ミドルウェア: 認証・CORS・ロガーは公式提供。サードパーティも豊富
(4) OpenAPI生成: @hono/zod-openapiでSchema-FirstなOpenAPI仕様を自動生成
(5) テスト: Honoアプリは関数なので、テストランナーから直接呼べる
実務で詰まる3つの落とし穴
- Cookieセッション: エッジ環境はステートレス前提。SessionストアはKV/Redis/Durable Objectsで外部化
- ファイルアップロード: マルチパートはWeb標準APIで扱うがバイナリ処理は要注意
- 長時間処理: Workers/Edgeはタイムアウト制限あり。バックグラウンド処理はQueueに逃がす
30日学習プラン
- 1週目:
npm create honoでひな形作成。CRUD APIをCloudflare Workersにデプロイ - 2週目: Zod Validatorで入力検証・ミドルウェアで認証実装
- 3週目: Hono Clientでフロントエンドからの呼び出しを型安全化
- 4週目: OpenAPI仕様自動生成・本番運用に必要なロギング・モニタリング統合
関連リンク
Cloudflare Workersは Cloudflare Workers深掘り、Bunとの組合せは Bun深掘り、Drizzleとの連携は Drizzle ORM深掘り を参照してください。Next.jsと組み合わせる場合は Next.js深掘り もどうぞ。