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つ増えた。今なら認証は自前セッションより、もう少し既製のものに寄せるかも。