2024年4月、honox で Hono ベースの SSR フレームワークを試した。Hono は API でよく使っていたので、フロントまで含めて Hono で完結したらどうなるか気になった回。
HonoX とは
Hono の上で JSX + SSR + islands(部分的なクライアント側 hydration)。Next.js より薄くて、Cloudflare Workers との相性が良い。app/islands/counter.tsx みたいに、動かしたい部分だけ island にする構成。
やったこと
ただ Hello World を出すだけだとつまらないので、メモアプリの足場 + ログイン設計 まで踏み込んでみた。
- Cloudflare D1 を使う前提で、マイグレーションを書いた(
migrations/0001_init.sql) memo/users/auth_tokensテーブルを定義app/routes/_middleware.tsでミドルウェアapp/routes/auth/index.tsxでメール入力 → セッション発行の流れを設計
export const POST = createRoute(async (c) => {
const email = (await c.req.formData()).get("email");
const { result: user } = await c.env.DB
.prepare("SELECT * FROM user WHERE email = ?")
.bind(email).first();
// いなければ新規作成、いればセッション作成 → cookie セットして TOP へ
return c.redirect("/");
});
実際このセッション処理は、コメントで流れだけ書いて中身は書きかけのまま。system_design/auth_sequense.mmd に認証のシーケンス図を Mermaid で置いて、「どう繋ぐか」を先に整理していた。
学び
HonoX は「Next.js いらないかも」層にちょうどいい。c.env.DB で D1 をそのまま叩けるので、Workers + D1 で完結する小さいアプリには十分。エコシステムはまだ小さいけど、個人の API + 軽い SSR なら戦える、という手応え。
おわり
ログインまわりを書き切る前に止まっているけど、D1 のマイグレーション → ミドルウェア → ルートの流れは掴めた。islands の考え方も含めて、Workers 前提で組むときの引き出しが1つ増えた。今なら認証は自前セッションより、もう少し既製のものに寄せるかも。