Ian Chou's Blog

為什麼我選擇了一條「少有人走的路」?—— 談 Next.js + Hono + Edge AI 的非主流電商架構

為什麼我選擇了一條「少有人走的路」?—— 談 Next.js + Hono + Edge AI 的非主流電商架構

在開始這個專案(Next-Edge-AI-Commerce)之前,我做了一番調研。我發現一個有趣的現象:雖然 Next.jsHonoCloudflare WorkersD1 以及 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 後台直接讀寫資料表。這樣做開發很快,但維護很痛,遷移更痛。

我的架構設計遵循以下原則:

這種 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」這個動作,我強制了系統必須具備極致的可移植性:

  1. 驗證邊界:當我切換資料庫時,我只需要修改 apps/api 裡的 DB Adapter。如果 Storefront 或 Admin 因為換了 DB 而報錯,那就證明我的架構失敗了——代表有邏輯洩漏到了 API 層之外。

  2. 確保 API 唯一性:這個策略迫使我必須確保 所有的 App (Storefront, Admin, AI Agent) 都是乖乖指向 API Endpoint,而不是依賴底層資料庫的實作細節。

這不僅僅是為了換資料庫,更是為了在架構層面 「把路走窄」,確保只有 API 這條路可走。

3. AI-Native Admin:為什麼我不需要 GUI?

在後台管理系統的設計上,我做了一個更大膽的嘗試:以 AI Chat 為核心介面

傳統電商後台充斥著表格、按鈕和繁瑣的 CRUD 表單。但對於運營者來說,他們的意圖往往很簡單:「把庫存低於 10 的商品補貨」、「把這季的熱銷品價格調高 5%」。

在這個架構中,AI 不再是側邊欄的輔助聊天機器人,它是 主要操作介面

這讓後台開發變得極度輕量——我不需要為了新增一個功能去刻兩個頁面的 UI,我只需要在 API 層增加一個 Tool 即可。

4. 結語:用工程紀律換取長期自由

這個專案的技術堆疊看起來很新潮,但背後的邏輯其實非常老派且嚴謹:關注點分離 (Separation of Concerns)

我利用 D1 到 Neon 的遷移規劃 作為檢驗架構的試金石,利用 Hono 作為唯一的邏輯樞紐,利用 AI 來簡化人機互動。

這是一套為了「長期維護」與「彈性擴展」而生的架構。如果你也對 Edge Computing、Serverless 架構以及 AI 驅動的開發模式感興趣,歡迎參考我的 GitHub 專案。

👉 GitHub Repo: next-edge-ai-commerce