從「總部大樓」到「全球快閃店」：為什麼我們把 Medusa 電商後端搬到了邊緣 (Edge)？
在傳統的電商架構中，Medusa 通常是一個運行在 Node.js 上的常駐服務。但我們做了一個大膽的架構重構：拆掉常駐伺服器，改用 Hono 框架運行在 Edge Functions（邊緣函數）上。
這不僅僅是換個寫程式的工具，而是從「集中式管理」轉向「分散式、按需服務」的根本變革。以下我們用兩種視角來解釋這件事。
🟢 給非技術夥伴（老闆、PM、行銷）：這對生意有什麼好處？
如果你不懂程式碼，沒關係。請想像我們正在經營一家連鎖餐飲服務。
1. 過去的作法：位於市中心的「中央大廚房」
傳統的 Medusa 架構，就像我們在台北市中心租了一層昂貴的辦公室，開了一間**「24小時不打烊的中央廚房」**。
- 成本高昂： 不管半夜有沒有人點餐，廚房燈都要亮著，水電要繳，廚師（伺服器資源）都要隨時待命領薪水。
- 距離限制： 如果紐約或倫敦的客人想點餐，我們得從台北做好了送過去，運送時間（延遲）非常長，送到時菜都涼了。
2. 現在的作法（Edge）：遍佈全球的「隨叫隨到快閃廚房」
我們現在改用的架構（Hono + Edge Functions），就像是取消了中央廚房，改成在全球 100 個城市的街角設立**「無人快閃廚房」**。
- 按需付費（省成本）： 平常這些廚房是關閉的（不花錢）。只有當客人下單的那一瞬間，廚房才會「通電啟動」，做完菜立刻斷電。我們只付「做菜那幾秒鐘」的錢，不再付「待命」的錢。
- 極致速度（體驗好）： 紐約的客人下單，紐約街角的快閃廚房直接出餐；台北的客人下單，由台北的節點處理。客人走在哪，服務就跟到哪。
一句話總結：
「我們從養一間永遠開著、燒錢的總店，變成了無數個『有單才開、做完就關』的全球微型分店。既省下了閒置成本，又讓國外客戶感覺網站變快了。」
🔵 給技術夥伴（工程師）：我們做了什麼架構升級？
對於開發團隊來說，這是一個從 Monolithic Node.js Server 遷移到 Edge-native Serverless 的過程。
1. 技術本質的改變
- Legacy Architecture (傳統 Medusa)：
原本 Medusa 是一個基於 Express/Node.js 的長駐行程 (Long-running Process)。它需要一台 VPS 或 Container (Docker)，並且需要處理記憶體管理、Keep-alive 連線，且通常部署在單一 Region (如us-east-1)。 - Next-Gen Architecture (Edge + Hono)：
我們將 Medusa 的商業邏輯拆解，並利用 Hono 這個超輕量、符合 Web Standards 的框架進行重寫或適配。這讓我們能將 API 部署到 Cloudflare Workers 或 Vercel Edge 等環境。
2. 為什麼選擇 Hono？
Medusa 原生依賴 Node.js 環境，但 Edge Runtime (如 V8 Isolate) 並不支援所有 Node API。Hono 是為了 Edge 生的框架，它體積極小、啟動速度極快 (Sub-millisecond cold start)，完美適配「無伺服器」的特性，充當了 Medusa 邏輯與 Edge 平台之間的最佳黏著劑。
3. 架構優勢
- No Cold Starts： 相比 AWS Lambda 傳統的 Cold start，Edge Functions 幾乎是瞬間啟動。
- Geo-Replication： 程式碼自動複製到全球數百個 CDN 節點，實現物理層面的 Low Latency。
- Infinite Scaling： 流量暴增時（如黑五促銷），不需要手動設定 Auto-scaling group，Edge 平台會自動水平擴展處理並發請求。
📝 總結：為什麼我們要這樣做？
這次的重構不只是為了「炫技」，而是為了達成三個具體的商業目標：
- 降低閒置成本： 讓伺服器費用與訂單量成正比，沒有訂單時成本趨近於零。
- 提升全球效能： 消除跨國傳輸的物理延遲，提升轉換率。
- 簡化維運： 不再需要管理伺服器的 OS 更新、安全補丁，將維運工作託管給邊緣平台。
這就是為什麼我們要把 Medusa 拆掉，搬到 Edge 的原因：用更聰明的架構，做更高效的生意。
- ← Previous
Next.js vs. Astro：打造高互動電商網站，創業者該如何選擇技術地基？