為什麼我決定放棄 Next.js + Auth.js，轉向 Hono + Better Auth？
在構建我的新專案 Next.js EC Site MVP (AI-Enhanced Edition) 時，我經歷了一次意外的架構轉向。
起初，我的想法非常「標準」：Admin 後台使用 Next.js，搭配業界標配的 Auth.js (NextAuth) 來處理身分驗證。這聽起來是最安全的選擇，對吧？畢竟 NextAuth 已經存在多年，生態系龐大。
然而，當我深入實作並試圖將其與我的 Cloudflare Workers (Hono) 後端整合時，我發現事情並沒有那麼簡單。隨著我對 Auth.js v5 現狀的挖掘，以及對新興挑戰者 Better Auth 的研究，我最終做了一個大膽的決定：砍掉 Admin 的 Next.js SSR 層，擁抱 Better Auth 與純 SPA 架構。
這篇文章將分享我為什麼做出這個決定，以及這對現代 Edge 架構意味著什麼。
1. 專案背景：一個分離式架構的電商平台
首先快速說明一下我的專案架構。這是一個針對中小企業設計的電商平台，核心特點是前後端分離與 Serverless/Edge 優先：
- Storefront: Next.js (部署於 Cloudflare Pages)
- API Gateway: Hono 運行於 Cloudflare Workers (核心邏輯層)
- Database: Cloudflare D1 (SQLite) -> Phase 2 遷移至 Neon Postgres
- Admin Dashboard: 原本計劃使用 Next.js + Refine (部署於 Vercel)
在原始的規劃（PRD）中，我把 Auth Model 放在 Admin (Next.js) 上。這意味著 Admin Server 負責登入狀態，然後透過 Shared Secret 與 API Gateway 溝通。
但就在我準備動工時，我發現了 Auth.js 生態圈的一個重大變化。
2. Auth.js v5 的困境與 Better Auth 的崛起
我原本打算使用 @hono/auth-js 來橋接 Hono 與 Auth.js，但我發現了幾個令人不安的事實：
- 永遠的 Beta 版：Auth.js v5 (原 NextAuth v5) 已經 Beta 了很長一段時間。官方維護資源似乎跟不上它龐大的表面積（支援所有框架）。
- 維護模式的轉變：近期社群與官方的動向顯示，Auth.js 的開發重心似乎正在轉移，甚至有併入 Better Auth 生態系的趨勢。
- Better Auth 是什麼？：這是一個由 TypeScript 構建、框架無關（Framework-agnostic）的現代認證庫。它不是像 Clerk 那樣的 SaaS，而是你可以自己託管的 Library，且功能驚人地完整（內建 2FA, Passkey, Multi-tenant, Session management）。
技術比一比：為什麼 Better Auth 贏了？
| 特性 | Auth.js (@hono/auth-js) | Better Auth |
|---|---|---|
| 定位 | NextAuth 的 Hono 適配器 (Adapter) | 專為 TypeScript 設計的完整認證框架 |
| Hono 整合度 | 第三方 Middleware 概念，文件較少 | 官方一等公民支援，文件完整 |
| Edge 支援 | 需自行處理相容性問題 | 原生支援 Cloudflare D1 / KV |
| 功能廣度 | 核心驗證為主，進階功能需自幹 | 內建 Plugin 系統 (2FA, Rate Limit, Org...) |
| 未來性 | 維護模式 (Maintenance Mode) | 活躍開發中 (Active Development) |
對於一個運行在 Cloudflare Workers 上的新專案來說，選擇一個 原生支援 D1 且 TypeScript First 的方案，顯然比硬接一個處於過渡期的 Auth.js 更具前瞻性。
3. 架構重構：從 Proxy 模式到直接驗證
這個技術選型的改變，連帶觸發了我對整體架構的重新思考。
❌ 原本的方案 (The "Next.js Heavy" Way)
- Admin (Next.js): 負責處理 Login UI、Cookie 和 Session。
- API (Hono): 不直接認識 User，只認由 Admin 轉發過來的 Request (帶著 Shared Secret)。
- 缺點： API 被 Admin 綁架了，且多了一層 Next.js Server 做 Proxy，架構變得臃腫。Admin 必須是 SSR。
✅ 新的方案 (The "Better Auth" Way)
- API (Hono): 直接整合 Better Auth。API 自己負責發 Cookie、驗證 Session、讀寫 D1 資料庫。
- Admin (Vite + React): 降級為純靜態的 SPA (Single Page Application)。它只需要打 API，瀏覽器會自動帶上 Cookie。
- 優點：
- 權責分明： 身份驗證回歸後端 API，這才是它該在的地方。
- 更輕量： Admin 不再需要 Node.js/Next.js Runtime，可以部署在任何 CDN (如 Cloudflare Pages) 上。
- 無狀態： API Gateway 完美契合 Serverless 模型。
4. 實作預覽：Better Auth + Hono
在 Hono (Cloudflare Workers) 上整合 Better Auth 意外地優雅。只需要幾行程式碼就能把 Auth API 掛載上去：
// apps/api/src/index.ts
import { Hono } from "hono";
import { auth } from "./lib/auth"; // Better Auth instance
import { cors } from "hono/cors";
const app = new Hono();
// 1. 設定 CORS (這對 SPA 很重要)
app.use("/api/*", cors({
origin: ["http://localhost:5173", "https://admin.mydomain.com"],
credentials: true, // 允許帶 Cookie
}));
// 2. 掛載 Better Auth Handler
app.on(["POST", "GET"], "/api/auth/*", (c) => {
return auth.handler(c.req.raw);
});
// 3. 保護你的 Routes
app.get("/api/products", async (c) => {
const session = await auth.api.getSession({ headers: c.req.raw.headers });
if (!session) return c.json({ error: "Unauthorized" }, 401);
// 業務邏輯...
return c.json({ data: "Secret Data" });
});
export default app;
而 Admin 前端（使用 Refine 或 React Admin）只需要指向這個 API URL，剩下的 Session 管理、Cookie 交換，Better Auth 的 Client SDK 都幫你處理好了。
5. 結論：擁抱變化，選擇長期價值
這次的轉折讓我學到重要的一課：不要因為「大家都這樣用」就停止評估新工具。 Next.js + NextAuth 曾經是黃金標準，但在 Serverless 與 Edge computing 崛起的今天，像 Hono + Better Auth 這樣更輕量、更模組化的組合，正在定義新的開發體驗。
總結這個架構轉向的收益：
- 省錢/省資源：Admin 變成靜態檔，不需要 Vercel Pro 或額外的 Compute 資源。
- 開發單純化：不再需要處理 Next.js App Router 與 Server Actions 的複雜度，回歸單純的 Client-Side Fetching。
- 未來的擴充性：Better Auth 內建的多租戶 (Multi-tenant) 功能，為我未來可能的 SaaS 化鋪平了道路。
如果你也在做 Cloudflare Workers 或 Hono 相關的開發，我強烈建議你試試 Better Auth。它可能會像改變我的專案一樣，改變你對後端驗證的想像。