そもそもNestJSを使っていたワケ
弊社では フロントエンドとバックエンドをTypeScriptで統一するというスタックを5年以上続けています。
その中でNestJSは
✅ TypeScriptサポート
✅ 公式ドキュメントが充実してて安心
✅ コーディングルールが明確でチーム開発がスムーズ
等の理由から採用しました。
そしてAPIに型を付けるために aspida を採用し、フロントエンドとバックエンド間での型の共通化を行っていました。
NestJS × aspidaの困りポイント
NestJSとaspidaの連携では、Swaggerを介した型生成に依存していました。
その過程で顕在化した課題は、「暗黙のルール遵守」 に神経を使う場面が多かったことです。
- swagger用のデコレータの癖
例えば配列を型定義する上で何パターンかのデコレータの付け方が存在します。
しかしswaggerと正しく連携させるためには特定のパターンを必ず用いる必要があります。 - 部分的に型が伝搬しない
Controller層、Service層、DTOと1つのAPIを作成する中でも、同じ型定義を明示的に複数回書かないと型安全にならない事象がありました。それにより型定義を明示的に書き忘れた際に実際の値と型定義が異なる状況を引き起こしました。
これらは慣れれば解決するものの
⛔ 新人さんへの負担が大きい
⛔ 別プロジェクトをやってると作法を忘れがち
⛔ 気づかないバグの温床になる
と解決が望ましい状況でした。
HonoのRPCが全部解決してくれる
HonoではRPCが利用可能です。
https://hono.dev/docs/guides/rpc
RPCとはざっくり バックエンドのAPIをフロントから関数のように呼べる仕組み くらいに思っておけばOKです。
そして関数で呼べるだけではなく、型定義が自動で共有されるから
✨ バックエンドの実装がそのままフロントの型定義になる
✨ デコレータのメンテナンスが不要
✨ APIを変更したら即座に関連箇所でエラー検出
といったことが可能になります。
弊社ではもともとTurborepoを用いたモノレポ構成を取っていたので、非常にスムーズな導入が可能でした。
AI時代に勝つカギは型管理
CursorのAIアシスタントやRoo CodeのようなコーディングAIが発達する今、型の正確性はますます重要になっています。なぜなら型エラーが発生した場合に自律的にエラーを修正してくれるからです。
将来的にAIがコーディングの90%以上を担うのは間違いないと感じており、その精度や自律性の向上には型を適切に扱うことが非常に重要になるでしょうね。
もっとHonoは気軽に使って良い
「Hono＝Cloudflare Workers」のイメージが強いかもしれませんが、実はどこでも動かせます。私たちはPrismaとの兼ね合いでCloudflare Workersは様子見中です。代わりに扱いやすく低コストから動かせるCloudRunへデプロイしています。
AI時代に取り残されない第一歩として、まずはHonoでRPCを試してみませんか？
きっと開発がもっとラクになるはずですよ👍