為什麼技術選型 CMS 我要選 Strapi？2024 年中的預算與系統分析決策

引言：一個技術選型的起點

2024 年 6 月，我坐在會議室裡，面對著老闆和行銷總監，準備報告我對公司新系統 CMS 的技術選型建議。這不是一個輕鬆的決定——選錯了，可能浪費數百萬的開發成本；選對了，能為公司省下可觀的人力支出。

經過數週的研究與分析，作為一個架構規劃師同時也是技術決策者，我最終選擇了 Strapi 作為我們的 Headless CMS 解決方案。這篇文章將分享我的決策過程、考量因素，以及最重要的——這個選擇如何為公司省下大筆預算。

什麼是 Headless CMS？

在深入 Strapi 之前，先理解 Headless CMS 的核心概念。

傳統 CMS vs Headless CMS

graph TB
    subgraph Traditional["傳統 CMS（如 WordPress）"]
        A[後端 + 資料庫] --> B[模板引擎]
        B --> C[HTML 輸出]
        C --> D[瀏覽器]
    end

    subgraph Headless["Headless CMS（如 Strapi）"]
        E[後端 + 資料庫] --> F[REST/GraphQL API]
        F --> G[Web App]
        F --> H[Mobile App]
        F --> I[IoT Device]
        F --> J[其他服務]
    end

傳統 CMS 將前端與後端緊密耦合，網站的外觀和內容管理綁在一起。而 Headless CMS 則專注於內容管理和 API 提供，讓前端團隊可以使用任何技術框架來消費這些 API。

Headless CMS 的核心優勢

為什麼選擇 Strapi？三大核心原因

原因一：前後端完全分離

Strapi 作為 Headless CMS，天生就是為了前後端分離而設計。這意味著：

graph LR
    subgraph Backend["Strapi 後端"]
        A[Content Manager] --> B[REST API]
        A --> C[GraphQL API]
        D[Admin Panel] --> A
    end

    subgraph Frontend["前端應用"]
        B --> E[Vue.js Web App]
        C --> F[React Native App]
        B --> G[Next.js SSR]
    end

    style Backend fill:#e1f5fe,color:#000
    style Frontend fill:#f3e5f5,color:#000

實際效益：

• 前端團隊可以使用最熟悉的框架（我選擇 Vue.js）
• 後端 API 可以同時服務網站和未來的 App
• 前後端可以獨立部署、獨立擴展
• 開發進度不會互相卡住

原因二：自動生成 API 和 Schema

這是我選擇 Strapi 最重要的原因——Content-Type Builder 功能讓我們可以在 Admin Panel 中直接設計資料結構，Strapi 會自動生成對應的 REST API 和 GraphQL API。

sequenceDiagram
    participant Admin as 管理員
    participant CTB as Content-Type Builder
    participant Strapi as Strapi Core
    participant API as API Layer
    participant DB as 資料庫

    Admin->>CTB: 建立 "Product" Content-Type
    CTB->>Strapi: 定義 Schema
    Strapi->>DB: 自動建立資料表
    Strapi->>API: 自動生成 CRUD API
    Note over API: GET /api/products
    Note over API: POST /api/products
    Note over API: PUT /api/products/:id
    Note over API: DELETE /api/products/:id

傳統做法 vs Strapi 做法：

graph TB
    subgraph Traditional["傳統後端開發流程"]
        T1[設計 DB Schema] --> T2[撰寫 Migration]
        T2 --> T3[建立 Model]
        T3 --> T4[撰寫 Controller]
        T4 --> T5[定義 Routes]
        T5 --> T6[撰寫 API 文件]
        T6 --> T7[單元測試]
    end

    subgraph Strapi["Strapi 開發流程"]
        S1[在 Admin 建立 Content-Type] --> S2[自動完成]
        S2 --> S3[立即可用的 API]
    end

    style Traditional fill:#ffcdd2,color:#000
    style Strapi fill:#c8e6c9,color:#000

這代表什麼？ 原本需要後端工程師花 2-3 天完成的 CRUD API，現在只需要 10 分鐘在 Admin Panel 點一點就完成了。

原因三：開源且可自架

Strapi 是 MIT License 的開源專案，這意味著：

• 零授權費用：不像 Contentful 或 Sanity 需要按用量付費
• 完全掌控：程式碼在自己手上，可以自由修改
• 資料主權：資料存在自己的伺服器，不用擔心供應商鎖定

技術選型過程：為什麼不選 Wagtail？

在選擇 Strapi 之前，我也認真評估過另一個強大的 Headless CMS——Wagtail。

Wagtail 的發現過程

當時公司的電子商城服務商是 Shopline，我很好奇他們後台用的是什麼技術。經過一番調查：

graph LR
    A[調查起點] --> B[Shopline 後台分析]
    B --> C[發現使用 Salesforce 生態系]
    C --> D[追溯到 Wagtail CMS]
    D --> E[使用工具和實作交叉驗證]

    style E fill:#fff3e0,color:#000

我自己把Wagtail在本地架起來，做一個prototype試了幾個功能，確認 Wagtail 確實是一個被大型電商平台採用的成熟方案。

Wagtail vs Strapi 比較

為什麼最終沒選 Wagtail？

一個字：人。

graph TB
    subgraph Reality["2024 台北市場現實"]
        R1[Python 後端團隊] --> R1a[數量稀少]
        R1 --> R1b[報價偏高]
        R2[Node.js 後端團隊] --> R2a[數量充足]
        R2 --> R2b[報價合理]
    end

    R1b --> X[預算超標]
    R2b --> Y[符合預算]

    style X fill:#ffcdd2,color:#000
    style Y fill:#c8e6c9,color:#000

當時在台北尋找外包商時，我發現：

1. Python 後端團隊非常稀少：有能力做 Django/Wagtail 的外包商屈指可數
2. 報價明顯偏高：大概比 Node.js 團隊貴 30-50%
3. 時程無法配合：稀缺的團隊案子排滿，無法配合我們的上線時間

相比之下，熟悉 Node.js 的開發團隊在台北隨處可見，報價合理，選擇性也多。

結論：技術再好，找不到人做也是白搭。

Strapi 的缺點：必須面對的現實

任何技術選型都必須誠實面對缺點，Strapi 也不例外。以下是我們實際使用後遇到的挑戰。

缺點一：Admin Panel 學習門檻因人而異

Strapi 的 Admin Panel 對於平常就有在操作商業軟體的人來說，其實上手不難，熟能生巧。但對於那些本身對辦公室商業軟體就沒什麼 sense 的人，就會覺得 Strapi 很難用。

graph TB
    subgraph UserTypes["使用者類型"]
        U1[有商業軟體操作經驗] --> U1a[CRM、ERP 使用者]
        U1 --> U1b[Excel 進階使用者]
        U1a --> OK[✅ 適應良好]
        U1b --> OK

        U2[缺乏軟體操作經驗] --> U2a[純文書處理]
        U2 --> U2b[只用基本功能]
        U2a --> NOK[❌ 需要額外培訓]
        U2b --> NOK
    end

    style OK fill:#c8e6c9,color:#000
    style NOK fill:#ffcdd2,color:#000

重點不是 Strapi 難不難，而是使用者的軟體素養。

缺點二：高度客製化需要額外 UI 層

如果你的後台需要非常客製化的 UI/UX，例如複雜的 Dashboard、特殊的審核流程、或品牌化的介面設計，就需要額外建立一層客製化的管理介面，再透過 API 串接 Strapi 的資料。

graph LR
    subgraph Layer1["Strapi 層"]
        A[Strapi Admin<br/>基礎內容管理] --> B[Strapi API]
    end

    subgraph Layer2["客製化前台層"]
        B --> C[Vue.js 客製化管理介面<br/>進階功能 + 品牌化 UI]
        C --> D[User-Friendly UI]
    end

    subgraph Users["使用者"]
        D --> E[行銷人員]
        D --> F[內容編輯]
        D --> G[客服人員]
    end

    style Layer2 fill:#fff3e0

額外 UI 層的成本分析(略估)

這筆「隱藏成本」必須在決策時納入考量。

成本效益分析：完整版

現在讓我們把所有成本都算進去，做一個更完整的分析。

人力成本計算

根據 2024 年台灣市場行情，資深後端工程師的月薪大約落在 7 萬到 9 萬 之間。

graph TB
    subgraph Traditional["傳統開發所需人力"]
        A[資深後端工程師 A] --> A1[設計 API 架構]
        A --> A2[撰寫 API 程式碼]
        B[資深後端工程師 B] --> B1[資料庫設計]
        B --> B2[維護與優化]
        C[後端主管] --> C1[Code Review]
        C --> C2[架構決策]
    end

    subgraph Strapi["使用 Strapi 所需人力"]
        D[全端工程師] --> D1[Strapi 設定]
        D --> D2[客製化需求]
        D --> D3[前端開發]
        E[前端工程師] --> E1[客製化管理介面]
    end

    style Traditional fill:#ffcdd2,color:#000
    style Strapi fill:#c8e6c9,color:#000

三年總成本比較

即使加上客製化 UI 的成本，三年下來仍可省下約 290 萬！

決策時的風險評估

任何技術選型都有風險，以下是我當時的考量：

風險與對策

為什麼不選其他方案？

給決策者的建議

根據我的經驗，選擇 Strapi 的適用情境：

✅ 適合使用 Strapi 的情況

• 有1個資深工程師或工程團隊可以處理技術問題
• 使用者有基本的商業軟體操作經驗
• 預算有限但需要快速上線
• 需要 API-First 的架構
• 未來可能需要支援 App

⚠️ 需要額外考量的情況

• 使用者完全沒有軟體操作經驗
• 需要高度客製化的後台介面
• 對 UI/UX 有嚴格要求

❌ 不建議使用 Strapi 的情況

• 完全沒有技術人員
• 需要開箱即用的完整方案
• 預算極度有限，無法負擔客製化 UI

結論：技術選型是一門藝術

回顧這次的技術選型，我學到幾個重要的經驗：

1. 技術選型不只是技術問題：更是商業決策，必須考慮成本、時間、人力
2. 沒有完美的解決方案：只有最適合當前情境的選擇
3. 量化效益很重要：用數字說服老闆比用技術術語有效得多
4. 人才市場是關鍵：再好的技術，找不到人做也是白搭（Wagtail 的教訓）
5. 誠實面對缺點：Strapi 的 Admin UI 確實需要使用者有一定的軟體素養

沒有任何框架或工具是萬能的，Strapi 也不是萬能的，但在我們的場景下——中小型專案、有技術團隊、預算有限、需要快速上線——它是一個極佳的選擇。

最終結果？ 專案在預定時間內上線，後端開發時間縮短了 60%，雖然我們額外花了四週規劃客製化管理介面(不包括實作時間)，但整體而言仍比自建後端省下大量成本和時間。老闆看到成本分析表後非常滿意——這就是一個成功的技術選型帶來的價值。

參考資源

官方文件

• Strapi 官方文件
• Strapi GitHub
• Wagtail 官方網站

延伸閱讀

• Headless CMS 比較指南
• Strapi vs Contentful 比較
• Strapi 部署最佳實踐