API開発においては、型定義・バリデーション・仕様書の管理が多くの開発者にとって大きな課題です。
@hono/zod-openapi を利用すると、1つの Zod スキーマから 型・バリデーション・OpenAPI 仕様書 を自動生成でき、この課題をシンプルに解決できます。
私たちが開発した勤怠管理システムでは、平日/休日の勤務パターンや勤怠承認状態の組み合わせなど、複雑な状態管理を型安全に実装する必要がありました。
本LTでは、この要件を @hono/zod-openapi を用いてどのように実現したのか、具体的なコード例を交えてお伝えします。
このトークでは、フロントエンドフレームワークで採用されることの多いFile-based Routingの概念をバックエンドのREST API開発にも適用し、スケーラブルで管理しやすいAPI設計を実現する方法について紹介します。
Honoの実装の柔軟性は開発者に大きな自由度を与えてくれますが、その自由さゆえにプロジェクトが成長するにつれてルーティングの管理が複雑化しがちです。
いくつかのルーティングパターンを比較しながら、File-based Routingを採用するに至った理由と、その具体的な実装方法について解説します。
File-based Routingで実装される場合1ファイル = 1エンドポイントとなり、ほとんどのファイルで似たような構造を取ります。
そのためファイルが満たすべきルールを明確に定義しやすく、Claude CodeをはじめとするAgent Coding系ツールとの相性も非常に良いです。
近年シェアを拡大しているSvelteKitというフレームワークがあります。 SvelteKitはフロントエンドフレームワークにSvelteを採用しており文法がHTMLに極度に似ているため直書きユーザーにもやさしいフレームワークです。
そしてSvelteKitではアダプターというシステムを採用しています。 そのシステムのおかげで公式のアダプター以外にもユーザー側がアダプターを作る事によって様々なホスティングサービスに対応させることが出来ます。 今回はその特性を活かしてSvelteKit用のHonoアダプターを作りました。
これによってSvelteKitで作ったプロジェクトをHono製のウェブサーバーに組み込むことが出来ます。
話す内容
serveStaticを自作する
hono公式のserveStaticは相対パスのみしかサポートしていません。
無ければ作ればいいじゃないかという事でhono公式のserveStaticをベースに自作しました。
公式アダプターの @sveltejs/adapter-node
をHonoに置き換える過程
SvelteKit公式のadapter-honoには元々express.js用のハンドラーが用意されています。 SvelteKitユーザーが使いやすいようにするためにこちらを参考に作成することにしました。
環境変数でのポート指定やハンドラー機能などはそのままにミドルウェアや静的ファイルサーバーなどをHonoに置き換えました。
成果物
介護・社会福祉業界向け勤怠管理システムで、数百のエンドポイントを持つ大規模Honoアプリケーションを運用しています。
本セッションでは、@hono/vite-build + bunを活用したビルド戦略の実装事例を紹介します。
話すこと
対象者
得られること
本セッションでは、@hono/zod-openapi を活用して、API Gateway と複数の API をひとつのスキーマ定義から一元管理する実践的な方法を紹介します。
私たちのサービスでは、Web アプリからのリクエストをすべて API Gateway に集約し、そこから背後の複数の API へと振り分けています。この「1対多」の構成をとりながらも、スキーマはひとつのパッケージにまとめられており、@hono/zod-openapi のコンフィグから Web→Gateway、Gateway→API の両方向に対してスキーマを生成しています。
これにより、リクエストのバリデーションやモック生成を含めて一貫性を保ちながら開発を進めることが可能になりました。また、BFF 的な構成やプロキシ的な利用にも応用でき、API 管理の工数削減と柔軟性を両立しています。
本LTでは、この仕組みの設計と運用の実例を通して、Hono でのスキーマ一元管理のメリットを共有します。
「2ちゃんねる」に代表されるスレッドフロート型掲示板は、日本のインターネット文化の象徴です。本トークでは、「ゼロちゃんねるプラス」を参考に、この伝統的な掲示板をHono, Bun, Cloudflare Workersといった令和の最新技術スタックで再構築した個人開発プロジェクト「VakKarma」についてお話しします。
開発の核としたのは、型安全性の徹底的な追求です。フロントエンドからバックエンド、データベースアクセスに至るまで、一貫して型安全な開発体験を目指しました。
UI構築には、Honoベースのメタフレームワーク「HonoX」を採用。JSXを用いてReactのような開発体験で型安全なHTMLを構築できる点が大きな魅力です。これにより、従来のテンプレートエンジンが抱える型情報の喪失といった課題を解決しました。
データベース操作には、ESLintプラグイン「SafeQL」を導入。SQLクエリを静的に解析し型情報を生成、タイプミスや型の不一致をコーディング中に検出することで、実行時エラーのリスクを大幅に低減させました。
アーキテクチャはドメイン駆動設計(DDD)を意識し、ドメイン層・ユースケース層・リポジトリ層に分割。堅牢で保守性の高いコードベースを構築しました。
また、専用ブラウザ(ChMate)からの接続もサポートし、JavaScriptを無効化した環境でも動作するよう、クライアントサイドのJSに依存しない設計を採用しています。デプロイ先の選択肢も複数対応しています。
このトークを通じて、HonoXを用いたモダンなWebアプリケーション開発の魅力と、型安全性を軸にしたシステム設計の実践的な知見を共有します。
Hono・Bun・Drizzleという軽量かつモダンな技術スタックは、小〜中規模では高い開発体験を提供しますが、100を超えるテーブルを抱える大規模アプリケーションと組み合わせると、型定義の肥大化、マイグレーション管理の複雑化などの課題に直面します。
本LTでは、これらの課題を実際の開発現場でどのように捉え、対処しているのかを共有します。
特にテスト戦略では、Drizzleのネストしたトランザクションへの対応を活かし、Honoの処理全体をテスト単位でラップしてロールバック可能にすることで、DB状態をクリーンに保ちながらテストを高速に繰り返せる環境を構築しました。さらに、マイグレーション実行などI/O負荷の高い処理では、Dockerのtmpfs機能を利用してDBストレージをインメモリ化し、テスト速度を大幅に改善しています。
これから大規模DBにHonoやBun、Drizzleを導入しようと考えている方が、事前に押さえておくべき注意点や実践知見を持ち帰れる内容です。