引言：一個技術選型的起點
2024 年 6 月，我坐在會議室裡，面對著老闆和行銷總監，準備報告我對公司新系統 CMS 的技術選型建議。這不是一個輕鬆的決定——選錯了，可能浪費數百萬的開發成本；選對了，能為公司省下可觀的人力支出。
經過數週的研究與分析，作為一個架構規劃師同時也是技術決策者，我最終選擇了 Strapi 作為我們的 Headless CMS 解決方案。這篇文章將分享我的決策過程、考量因素，以及最重要的——這個選擇如何為公司省下大筆預算。
什麼是 Headless CMS？
在深入 Strapi 之前，先理解 Headless CMS 的核心概念。
傳統 CMS vs Headless CMS
傳統 CMS 將前端與後端緊密耦合，網站的外觀和內容管理綁在一起。而 Headless CMS 則專注於內容管理和 API 提供，讓前端團隊可以使用任何技術框架來消費這些 API。
Headless CMS 的核心優勢
| 特性 | 傳統 CMS | Headless CMS |
|---|---|---|
| 前後端耦合 | 緊密耦合 | 完全分離 |
| 前端技術選擇 | 受限於 CMS 模板 | 任意框架（Vue、React、Flutter） |
| 多平台支援 | 僅限網頁 | Web、App、IoT 皆可 |
| 擴展性 | 中等 | 極高 |
| API 優先 | 否 | 是 |
為什麼選擇 Strapi？三大核心原因
原因一：前後端完全分離
Strapi 作為 Headless CMS，天生就是為了前後端分離而設計。這意味著：
實際效益：
- 前端團隊可以使用最熟悉的框架（我選擇 Vue.js）
- 後端 API 可以同時服務網站和未來的 App
- 前後端可以獨立部署、獨立擴展
- 開發進度不會互相卡住
原因二：自動生成 API 和 Schema
這是我選擇 Strapi 最重要的原因——Content-Type Builder 功能讓我們可以在 Admin Panel 中直接設計資料結構，Strapi 會自動生成對應的 REST API 和 GraphQL API。
傳統做法 vs Strapi 做法：
這代表什麼？ 原本需要後端工程師花 2-3 天完成的 CRUD API，現在只需要 10 分鐘在 Admin Panel 點一點就完成了。
原因三：開源且可自架
Strapi 是 MIT License 的開源專案，這意味著：
- 零授權費用：不像 Contentful 或 Sanity 需要按用量付費
- 完全掌控：程式碼在自己手上，可以自由修改
- 資料主權：資料存在自己的伺服器，不用擔心供應商鎖定
技術選型過程：為什麼不選 Wagtail？
在選擇 Strapi 之前，我也認真評估過另一個強大的 Headless CMS——Wagtail。
Wagtail 的發現過程
當時公司的電子商城服務商是 Shopline，我很好奇他們後台用的是什麼技術。經過一番調查：
我自己把Wagtail在本地架起來，做一個prototype試了幾個功能，確認 Wagtail 確實是一個被大型電商平台採用的成熟方案。
Wagtail vs Strapi 比較
| 項目 | Wagtail | Strapi |
|---|---|---|
| 程式語言 | Python (Django) | Node.js (JavaScript) |
| 成熟度 | 非常成熟 | 成熟 |
| Admin UI | 優秀、友善 | 中等 |
| 台灣開發者生態 | 較少 | 較多 |
| 外包報價 | 偏高 | 合理 |
為什麼最終沒選 Wagtail？
一個字：人。
當時在台北尋找外包商時，我發現：
- Python 後端團隊非常稀少：有能力做 Django/Wagtail 的外包商屈指可數
- 報價明顯偏高：大概比 Node.js 團隊貴 30-50%
- 時程無法配合：稀缺的團隊案子排滿，無法配合我們的上線時間
相比之下，熟悉 Node.js 的開發團隊在台北隨處可見，報價合理，選擇性也多。
結論：技術再好，找不到人做也是白搭。
Strapi 的缺點：必須面對的現實
任何技術選型都必須誠實面對缺點，Strapi 也不例外。以下是我們實際使用後遇到的挑戰。
缺點一：Admin Panel 學習門檻因人而異
Strapi 的 Admin Panel 對於平常就有在操作商業軟體的人來說，其實上手不難，熟能生巧。但對於那些本身對辦公室商業軟體就沒什麼 sense 的人，就會覺得 Strapi 很難用。
重點不是 Strapi 難不難，而是使用者的軟體素養。
缺點二：高度客製化需要額外 UI 層
如果你的後台需要非常客製化的 UI/UX，例如複雜的 Dashboard、特殊的審核流程、或品牌化的介面設計，就需要額外建立一層客製化的管理介面，再透過 API 串接 Strapi 的資料。
額外 UI 層的成本分析(略估)
| 項目 | 預估工時 | 預估成本 |
|---|---|---|
| 需求分析與 UI 設計 | 40 小時 | 40,000 TWD |
| 前端開發（Vue.js/React） | 120 小時 | 120,000 TWD |
| API 整合與測試 | 40 小時 | 40,000 TWD |
| 後續維護（每月） | 16 小時 | 16,000 TWD/月 |
| 一次性開發總成本 | - | 200,000 TWD |
這筆「隱藏成本」必須在決策時納入考量。
成本效益分析：完整版
現在讓我們把所有成本都算進去，做一個更完整的分析。
人力成本計算
根據 2024 年台灣市場行情，資深後端工程師的月薪大約落在 7 萬到 9 萬 之間。
三年總成本比較
| 項目 | 傳統自建方案 | Strapi + 客製 UI |
|---|---|---|
| 後端人力（36 個月） | 16 萬 × 36 = 576 萬 | 0 |
| 全端/前端人力（36 個月） | 6 萬 × 36 = 216 萬 | 12 萬 × 36 = 432 萬 |
| 客製化 UI 開發（一次性） | 0 | 20 萬 |
| 客製化 UI 維護（36 個月） | 0 | 1.6 萬 × 36 = 57.6 萬 |
| 伺服器費用（36 個月） | 1 萬 × 36 = 36 萬 | 0.8 萬 × 36 = 28.8 萬 |
| 三年總成本 | 828 萬 | 538.4 萬 |
| 節省金額 | - | 289.6 萬 |
即使加上客製化 UI 的成本，三年下來仍可省下約 290 萬！
決策時的風險評估
任何技術選型都有風險，以下是我當時的考量：
風險與對策
| 風險 | 可能性 | 影響 | 對策 |
|---|---|---|---|
| Strapi 專案停止維護 | 低 | 高 | 開源社群活躍，可 Fork 自維護 |
| 效能瓶頸 | 中 | 中 | 可透過快取和資料庫優化解決 |
| 功能不足需客製 | 高 | 低 | Strapi 支援 Plugin 和自訂 API |
| 團隊學習曲線 | 中 | 低 | 官方文件完善，社群資源豐富 |
| Admin UI 不符需求 | 高 | 中 | 預先規劃客製化 UI 預算 |
為什麼不選其他方案？
| 方案 | 排除原因 |
|---|---|
| Wagtail (Python) | 台北 Python 團隊稀少、報價過高 |
| WordPress + REST API | 效能差、架構老舊、安全性疑慮 |
| Contentful | SaaS 收費高，資料不在自己手上 |
| Sanity | 同上，且台灣用戶較少 |
| 自建 Node.js API | 開發時間長，需要更多人力 |
給決策者的建議
根據我的經驗，選擇 Strapi 的適用情境：
✅ 適合使用 Strapi 的情況
- 有1個資深工程師或工程團隊可以處理技術問題
- 使用者有基本的商業軟體操作經驗
- 預算有限但需要快速上線
- 需要 API-First 的架構
- 未來可能需要支援 App
⚠️ 需要額外考量的情況
- 使用者完全沒有軟體操作經驗
- 需要高度客製化的後台介面
- 對 UI/UX 有嚴格要求
❌ 不建議使用 Strapi 的情況
- 完全沒有技術人員
- 需要開箱即用的完整方案
- 預算極度有限，無法負擔客製化 UI
結論：技術選型是一門藝術
回顧這次的技術選型，我學到幾個重要的經驗：
- 技術選型不只是技術問題：更是商業決策，必須考慮成本、時間、人力
- 沒有完美的解決方案：只有最適合當前情境的選擇
- 量化效益很重要：用數字說服老闆比用技術術語有效得多
- 人才市場是關鍵：再好的技術，找不到人做也是白搭（Wagtail 的教訓）
- 誠實面對缺點：Strapi 的 Admin UI 確實需要使用者有一定的軟體素養
沒有任何框架或工具是萬能的，Strapi 也不是萬能的，但在我們的場景下——中小型專案、有技術團隊、預算有限、需要快速上線——它是一個極佳的選擇。
最終結果？ 專案在預定時間內上線，後端開發時間縮短了 60%，雖然我們額外花了四週規劃客製化管理介面(不包括實作時間)，但整體而言仍比自建後端省下大量成本和時間。老闆看到成本分析表後非常滿意——這就是一個成功的技術選型帶來的價值。