為什麼我選擇了一條「少有人走的路」?—— 談 Next.js + Hono + Edge AI 的非主流電商架構
為什麼我選擇了一條「少有人走的路」?—— 談 Next.js + Hono + Edge AI 的非主流電商架構
在開始這個專案(Next-Edge-AI-Commerce)之前,我做了一番調研。我發現一個有趣的現象:雖然 Next.js、Hono、Cloudflare Workers、D1 以及 Vercel AI SDK 這些技術單獨來看都已經非常成熟且熱門,但將它們組合成一套 「Storefront (Next.js) + API (Hono/Edge) + Admin (AI-Native) + Database Migration Strategy」 的完整架構,市面上卻幾乎找不到案例。
這並不是因為這條路行不通,而是因為這挑戰了傳統全端開發的直覺。
今天我想分享為什麼我要構建這個「非主流」的架構,以及我如何利用 資料庫遷移策略 作為一種強制手段,來確保系統的解耦與可維護性。
1. 核心理念:Edge First 與 API-Centric
傳統的電商開發往往是「單體式」或「緊耦合」的。開發者習慣直接在 Next.js 的 Server Actions 裡連線資料庫,或者讓 Admin 後台直接讀寫資料表。這樣做開發很快,但維護很痛,遷移更痛。
我的架構設計遵循以下原則:
-
Storefront (Next.js):只負責「呈現」,部署在 Cloudflare Pages 或 Vercel。
-
API (Hono):部署在 Cloudflare Workers,它是唯一的「資料守門員」。
-
Database:位於 Edge (D1) 或 Serverless Cloud (Neon)。
這種 API-Centric 的設計意味著:沒有任何前端應用(無論是 Storefront 還是 Admin)有資格直接觸碰資料庫。
2. 關於「D1 遷移至 Neon」的策略思考
這是這個專案最核心、也最容易被誤解的設計。
在 MVP 階段 (Phase 1),我選擇使用 Cloudflare D1 (SQLite);而在規劃的 Phase 2,我準備遷移至 Neon (Serverless Postgres)。
很多人會問:「為什麼不一開始就用 Neon?這樣不是多工嗎?」
其實,這是我刻意設計的 「架構壓力測試」(Architecture Stress Test)。
強制解耦的手段
如果我一開始就選定了一個強大的 DB(如 Neon),在開發過程中,我很可能會為了圖方便,在某個前端元件裡偷偷 import DB client,繞過 API 層直接查詢。這種「抄捷徑」的行為是架構腐敗的開始。
通過規劃「從 D1 遷移到 Neon」這個動作,我強制了系統必須具備極致的可移植性:
-
驗證邊界:當我切換資料庫時,我只需要修改
apps/api裡的 DB Adapter。如果 Storefront 或 Admin 因為換了 DB 而報錯,那就證明我的架構失敗了——代表有邏輯洩漏到了 API 層之外。 -
確保 API 唯一性:這個策略迫使我必須確保 所有的 App (Storefront, Admin, AI Agent) 都是乖乖指向 API Endpoint,而不是依賴底層資料庫的實作細節。
這不僅僅是為了換資料庫,更是為了在架構層面 「把路走窄」,確保只有 API 這條路可走。
3. AI-Native Admin:為什麼我不需要 GUI?
在後台管理系統的設計上,我做了一個更大膽的嘗試:以 AI Chat 為核心介面。
傳統電商後台充斥著表格、按鈕和繁瑣的 CRUD 表單。但對於運營者來說,他們的意圖往往很簡單:「把庫存低於 10 的商品補貨」、「把這季的熱銷品價格調高 5%」。
在這個架構中,AI 不再是側邊欄的輔助聊天機器人,它是 主要操作介面。
-
Intent-based Operations:管理者輸入自然語言,AI 解析意圖。
-
Tool Calling:AI 呼叫後端的 Hono API 執行動作。
-
Safety Rails:對於寫入操作(改價、庫存),系統強制要求「摘要確認」與「審計日誌 (Audit Log)」。
這讓後台開發變得極度輕量——我不需要為了新增一個功能去刻兩個頁面的 UI,我只需要在 API 層增加一個 Tool 即可。
4. 結語:用工程紀律換取長期自由
這個專案的技術堆疊看起來很新潮,但背後的邏輯其實非常老派且嚴謹:關注點分離 (Separation of Concerns)。
我利用 D1 到 Neon 的遷移規劃 作為檢驗架構的試金石,利用 Hono 作為唯一的邏輯樞紐,利用 AI 來簡化人機互動。
這是一套為了「長期維護」與「彈性擴展」而生的架構。如果你也對 Edge Computing、Serverless 架構以及 AI 驅動的開發模式感興趣,歡迎參考我的 GitHub 專案。
👉 GitHub Repo: next-edge-ai-commerce
- ← Previous
為什麼我決定放棄 Next.js + Auth.js,轉向 Hono + Better Auth? - Next →
LangChain Agent 治理之道:如何在「管住」與「管死」之間找到架構的平衡