NestJSからHonoへ：使ってみて感じた違いと学び

はじめに

メディカルフォースは業界に特化したSaaSを開発・提供しており美容医療の次の業界として警備業向けのプロダクトの開発を進めています。
美容医療のプロダクトではNestJSを使っていましたが、警備業向けのプロダクトではHonoを採用しました。
今回は、実際に使ってみてどう感じたかに焦点を当てて書いてみます。

NestJSを使っていたときの印象

NestJSは、DIやデコレーターなどが整っていて一見「フルスタック感」のあるフレームワークです。
ただ、使っていくうちに「便利さ」と「複雑さ」が表裏一体だと感じる場面が多くありました。

良かった点

• DIが標準搭載されている
  フレームワーク内で依存関係注入が完結するのは便利でした。

大変だった点

• Serviceがfatになりやすい
  NestJSではControllerの下の層がServiceのみとなっていましたが、1つのControllerに対し1つのサービスを書いていると肥大化しやすかったりロジックが複数のServiceに分散したりしていました。
• DIのためのデコレータの記述が分かりづらく冗長に感じる
  例えばModuleを定義するためのModuleデコレータでは引数にproviders,controllers,imports,exportsがあるがこれらが何のためのものか直感的でなく理解するのが難しかったです
• middleware周りで似たような概念が多く学習コストが高い
  Guard、Interceptor、Pipeなど似た概念が多く、理解と運用にコストがかかりました。
• ドメインとプレゼンテーションの分離が難しい
  NestJSのレイヤー構造に引っ張られ、アーキテクチャを自分たちで設計しにくかったです。

結果としてフレームワーク主導の設計になってしまい、「ドメインロジックを主役にした構成」 にたどり着くまでに時間がかかってしまいました。

Honoを使ってみて感じたこと

Honoは非常に軽量で、ルーティングとレスポンス処理に特化しています。
フレームワークとしてやることが明確なぶん、自分たちのアーキテクチャを自由に組み立てやすい のが特徴です。

1. DDDとの相性が良い

Hono自体はプレゼンテーション層に特化しているため、
ユースケース層やドメイン層をDDDのレイヤードアーキテクチャに従って構築しやすいです。
「どこにロジックを書くか」で迷うことが少なくなり、設計の意図をチーム全体で共有しやすくなりました。

2. middlewareがシンプルで扱いやすい

NestJSではGuardやInterceptorなど複数の概念がありましたが、Honoはmiddlewareが一本化されていてシンプル。
処理の流れを追いやすく、動作の予測もしやすいです。
「どこに何を書くか」で迷う時間が減り、開発効率が上がりました。

3. 学習コストが低く、小規模チームでもスピードを維持できる

Honoは構成がシンプルなので、フロントエンド寄りのエンジニアでもすぐに理解できます。
新しいメンバーが入ってもキャッチアップが早く、立ち上げ期のスピード感を維持できました。

開発体験の変化

実際にHonoを使って開発してみて感じたのは、
「フレームワークに合わせる開発」から「アーキテクチャを中心に据えた開発」 に変わったということです。

結果として、コード全体の見通しが良くなり、ドメインモデルを育てやすい開発スタイルに変わりました。

まとめ

Honoを使ってみて感じたのは、「必要なことだけをやる」設計が気持ちよくできるという点です。
これまでの経験を経て自分たちの設計を主軸にすることの大切さを実感でき、シンプルな土台の上に自分たちのアーキテクチャを載せていけることがフレームワーク選定において重要だと感じました。