トーク

Astroは本体のコンポーネント言語としてはJSXを第一級ではサポートしていません。
そのうえで、Astroに「もうひとつの選択肢としてのJSX」を取り入れるなら、Hono JSXが最適な候補になり得ると考えています。

理由はシンプルです。Astroの「サーバー優先・必要な所だけ動かす」思想に、Hono JSXの素直さと軽さがそのまま一致するから。さらにAstro公式ロードマップ（JSX対応の検討、部分描画、フォーム処理の改善など）とも方向性が揃っています。

本セッションでは、次の点を設計の観点から整理して共有します。

• Astro core team でJSXを検討する議論の中で、Hono JSXが有力候補となる理由
• 実験的レンダラーの構成と実装の要点
• .astro と並走できる最小の利用パターンとガイド
• 段階的な検証内容と結果、および今後の課題

REST API開発において、Honoを用いて、OpenAPIを作成する場合、Hono OpenAPIとZod OpenAPI Honoという選択肢があります。しかし、コードファーストのアプローチがメインです。スキーマファーストのアプローチが欲しかったため、hono-takibiというライブラリを作成し、試行錯誤しています。

「スキーマ駆動で、Zod OpenAPI Honoによる、API開発するために、Hono Takibiというライブラリを作っている」という、LTでも申し込みましたが、レギュラートークでも申し込みます。

OpenAPIやTypeSpecのスキーマ定義から、Zod OpenAPI Honoのコードを生成し、スキーマ駆動のHonoのアプローチを紹介します。

--- LT枠でも応募しているんですが、5分だとだいぶ切り詰める必要がありそうなので、レギュラートーク枠でも応募します ---

Hono・Bun・Drizzleという軽量かつモダンな技術スタックは、小〜中規模では高い開発体験を提供しますが、100を超えるテーブルを抱える大規模アプリケーションと組み合わせると、型定義の肥大化、マイグレーション管理の複雑化などの課題に直面します。
本LTでは、これらの課題を実際の開発現場でどのように捉え、対処しているのかを共有します。
特にテスト戦略では、Drizzleのネストしたトランザクションへの対応を活かし、Honoの処理全体をテスト単位でラップしてロールバック可能にすることで、DB状態をクリーンに保ちながらテストを高速に繰り返せる環境を構築しました。さらに、マイグレーション実行などI/O負荷の高い処理では、Dockerのtmpfs機能を利用してDBストレージをインメモリ化し、テスト速度を大幅に改善しています。
これから大規模DBにHonoやBun、Drizzleを導入しようと考えている方が、事前に押さえておくべき注意点や実践知見を持ち帰れる内容です。