はじめに
Hono Conference in Tokyo 2026に行ってきましたので、登壇内容の感想要約を投稿します。
ワークアラウンドで終わらせず、OSS を直す ～satto workspace の共同編集で見つけた WebSocket 接続の不具合～
共同編集機能で問題が起きた。
101のヘッダーにjwt更新のトークがなかったため、新しいjwtが受け取れないため、認証に失敗する問題点が発生した。
原因はOSSライブラリだった。
暫定対応として、websoket接続前にCookie更新用APIを用意した。これにより、ライブラリの修正を取り込みやすくした。
そもそも利用しているライブラリが非推奨になる予定だった。
Honoが叶える、いつでも降りられるLambdalith
大量のLambdaは、以下問題がある。
- 書き捨てられた関数がある。
- 処理が共通化されていない。
元々Lambdaは単体の関数を推奨していた。
しかし個別向けの実装が多くなってしまう問題点が多くなる。
またAIは個別最適な実装をしたり、たくさんの関数を読み取ってしまい、トークンを消費してしまう。
証明書更新するために、非同期で更新したい。
しかし複雑にLambdaが連携するようなっていため、テストやデプロイが難しくなっていた。
解決するため、Lambdalithをやることにした。
それでデプロイが早くなったり、普通のアプリケーションみたいな開発をすることができる。
その代わりに、権限管理が難しくなる。
Lambdalithにしたら、書き捨ての関数を集約しても、処理のルーティングが単純なifでテストがしづらい。
そのために機能性が高いhonoを採用にすることをした。
honoはLambdaイベントをhttpリクエストにしてくれる。それで処理のルーティングがやりやすくなる。
テストも引数にLambdaイベント内容を渡すだけで完了できる。
honoはECSに移行しやすい。
起動処理を書き換えるだけ。
個人開発者よ、Honoを使え
高校生1年生の発表。
個人開発の敵は、複雑さ(境界、状態管理、デプロイ先、お金)。
小説等声サイトを作っていたが、NEXTjs&vercelでAPIの整備ができなかったため、表示に1分かかってしまった。
honoで作り直した。
UIはReact、NEXTjsを使わなかった。
内臓のhtmlとJSXで作成した。
必要になってから、複雑化したした方がいいと感じた。
特に個人開発は単純さがとても重要になる。
Cloudflareとの相性がいいため、インフラエンが安くできる。
トークンレスCSRF対策の現在地 〜Content-Typeヘッダの落とし穴〜
honoに昔あった脆弱性を紹介する。
honoのcsrfライブラリを使うだけで、csrfを防げる。
24年10月にcsrfを突破できる脆弱性が見つかった。
サーバの許可なしで送信されるリクエストは限られている。
ブラウザは大文字小文字を判別しない。
そのため、許可の判断を大文字小文字出する場合、すり抜ける問題がある。→修正済み。
honoはContent-Typeなしのリクエストを受け取って許可してしまう問題もあった。→修正済み
csrf対策
getで更新処理を書かない。
ライブラリは開発が活発なもの
ライブラリは定期更新する。
判定ロジックはライブラリに任せる。
Hono CLI の これまで と これから
hono cliはhono conference2025で発表した。
hono cliは人間とAIが使うためのもの。
hono requestコマンドは、AIが開発サーバーを立てまくってポートが乱立する問題を解決するために生まれた。
6月に人間ではなく、AIのためのツールとして作るコンセプトになった。
AIに推測させずに、計測をさせる。
各機能をAI向けにチューニングした。
AIにはAIのDXがある。
AIの特性を理解した上で、AIに合わせた開発体験を提供する。
OSTでジュニアの教育について話した。
