Why Hono なぜHonoを使うべきなのか

なぜHonoを使うべきなのか？
サーバーサイドTypeScriptを専門とし
複数社でエンジニア、顧問業務を行ってきた著者が解説する

こちらは2025/2/18に実施されたFindyでのイベントの登壇スライドです
https://findy.connpass.com/event/343549/

Transcript

1. Why Hono? なぜHonoを使うべきなのか？ 2025/2/18 Hono活用を徹底解説 先達に学ぶベストプラクティス 発表者: RIóN: withChummy開発者 (@rio_devops
2. 簡単な自己紹介 私について ・Next.js, ServerSide TypeScript, AWS ・技術負債解消/ 大規模トラフィック / サーバーサイドTypeScriptが専門 ・今までに複数社で開発エンジニアや技術顧問を歴任してきた →その中で複数のHono PJをはじめ、 Express.js , NestJS, Hasura(GraphQL, Next.js API Routes, Server Actions)など一通り経験しHonoが第一候補に
3. Why Hono? なぜHonoを使うべきなのか？ 今日のテーマ ・Nest.js, Express.js, Hasura(GraphQL, tRPCと色々な選択肢がある中で 複数プロダクトでHonoを使って開発してきた観点からなぜ Honoを推すのか？を語る
4. What is Hono? Honoが持つ4つの特徴 Ultrafast & Lightweight Multi-runtime Batteries Included Delightful DX →これらの特徴が現代サーバーサイド TS開発における Painを解消してくれる
5. Honoを私なりに一言で言い表すと 今までのサーバー TS開発の課題を一手に解決してくれる 新世代フレームワーク ・ルーティング、型補完、型共有、バリデーション、built in機能としてOpen API生成 などサーバーサイド TS開発におけるメジャーなボトルネックを解決 してくれる ・Web標準に準拠 しておりバンドルサイズが軽量、高速 ・Adaptorが差分を吸い取ってインフラ環境にかかわらずデプロイ することができる
6. 現代サーバーサイド TS開発におけるボトルネック ・フロント、バックで型が共有されないと二重管理になってしまう ・アプリニーズが高くなるにつれて、バリデーションを効かせて堅牢で壊れにくいアプリ を作り保守を容易にしたいニーズが高い ・サーバーTSが専門である人は必ずしも多いわけではないので、 学習コストが高くなくフロント~バックまでスピーディに実装を完了させたい ・チーム開発での差分によって壊れたりせず、開発体験がよく、フロント〜バックみん ながストレス少なく開発ができるようなFWが欲しい
7. サーバーサイド FW選定の勘所 ・プロダクトはフロント、バック、インフラそれぞれの観点から考える必要があるので できるだけそれぞれに寄り添うようなフレークワークが望ましい ・それによってフロントエンドの設計実装が大変 になってしまったり、 環境差分をあれこれと考えてデプロイや保守が大変 になることは避け、 サーバーサイド側の都合により過ぎにならない ことでバランスを保ちたい ・できるだけ軽量で高速 に動くようなフレームワークが望ましいSEO、UXの観点) ・できるだけ壊れにくく堅牢な設計ができるフレームワークが望ましい
8. サーバーサイド TSにおけるFW選定. 1 ・FWは必要だから入れるのであって必要なければ入れる必要はない 例えばCLIでは生のサーバーサイドTypeScriptコードを書いて動かすことは有力候補 ・ところが、世の中の多くのサーバーサイドTSのプロジェクトが APIとして機能をしてリクエストを受けてレスポンスを返す ことが要件として必要 ・この機能を満たすのがいわゆるRouter で、 Express, Nest, Hasura, Next.js, Hono 主要なFWはどれもRouter機能を備えている ・FWには色々な機能がある中で、Routerがアプリを作る上で核になる部分である → 核であるRouterが機能していればどのFWでもAPIを作ることはできる。 RouterがFW核としてあって案件それぞれで必要なlibを入れて要件を満たすイメージ
9. サーバーサイド TSにおけるFW選定. 2 ・サーバーサイド TSにおけるFW選定. 1 で見たように 多くのサーバーサイドTSの用途がAPIサーバーだと考えると最も大事な機能 (核)はRouter ・Honoには5種類のRouterが用意されている (RegExp Router, Trie Router, Smart Router, Linear Router, Pattern Router) ・RouterはそれぞれのFWで提供されているので、 あとはサイズや速度、堅牢性、型共有、開発効率、ミドルウェアの充実度などから比較
10. サイズ、速度 ・ˮHono is so small. With the hono/tiny preset, its size is under 14KB when minified. There are many middleware and adapters, but they are bundled only when used. For context, the size of Express is 572KB.ˮ ・ˮHono is the fastest, compared to other routers for Cloudflare Workers.” https://hono.dev/docs/
11. 堅牢性 ・現代アプリ開発では堅牢性、いわゆる壊れにくさやトレランシーが重視される ・HonoではZodと互換性が非常に高くきめ細やかなバリデーションを行える
12. 型共有、開発効率 ・Schemaを定義してそれを型としてバックエンドとフロントエンドで共通利用できる ・これによって型安全になりフロントとバックでダブって型を書く必要がない ・Zod Open APIが内蔵されているのでOpen APIをスキーマから自動生成 できる
13. 結論 ・サーバーサイドTypeScriptのFWの第一候補としてHonoを考えて良い サイズ、速度、堅牢性、型共有、開発効率 の主要な観点からHonoが上位 ・新規で採用する場合は Hono(サーバーサイド)を初期から入れて開発を進め、 既存プロダクトに組み込む場合は一部から 組み込んで様子を見るのも⚪ ・APIだけでなくBFFに採用して各Clientに容易に型提供的なこともできる ・with Honoで既存サーバTS開発のつらみから解放されて快適な開発ライフを！
14. Honoの採用イメージ 1. ToB向け多機能 SaaS開発 ・高速な開発サイクルが求められるフェーズ ・フロント、バックまで一気通貫でモノレポ開発 ・多機能ToBSaaSなのでロジックが複雑でバリデーションをしっかりしたい → Honoの堅牢性とフロント・バックで一気通貫で開発できる強みを活かす
15. Honoの採用イメージ 2. インフラ系企業むけ API開発 ・何より手堅く開発を行うことができて堅牢さが求められるフェーズ ・APIなのでフロント、バックチームは別々にあるイメージ ・納期があるクライアントワークなので素早く開発を行うことが求められる案件 → Honoで高速に開発して Open APIは自動生成しフロントチームと連携
16. Honoの採用イメージ 3. ToC向けアプリ開発 ・できるだけ状況に即したバリデーションの結果を文言として返す ・多くの個人情報を扱う都合上、堅牢でセキュアである必要がある ・アプリとしての速度が求められ、 SEOという観点まで求められる → Honoのバリデーションをフル活用しつつ高速にページを返す
17. It is your turn! Honoについて学びを深め、 いつか一緒に働ける日を楽しみにしています！ エンジニア、技術顧問のお仕事も随時受け付けています〜
18. 最後に (ご協力のお願い ・獣医師とのカウンセリングアプリ の開発 with Honoに伴って、 カウンセリングの体験参加にご協力いただける方 を絶賛募集中です ・ペットを飼いたいけど自信がない 、 飼っている犬猫が元気がなくて不安 だ、 お別れに伴う家族メンバーのメンタルケア まで、 獣医師がペットの悩みを聞いてカウンセリングします ・QRを読み込んで体験カウンセリング に進む1分程度