這篇文章整理自一場關於現代 Web 架構的深度討論。我們將從最基礎的靜態託管開始，一路探討到複雜的後端架構選擇，特別是針對希望「專注於後端 API 開發」的工程師，該如何構建最有效率的開發環境。
1. GitHub Pages：被低估的神器
許多人只把 GitHub Pages 當作放個人履歷的地方，但它實際上是一個企業級的靜態內容託管服務。
1.1 它不只是存放檔案
GitHub Pages 的背後透過 Fastly CDN (Content Delivery Network) 進行全球分發。這意味著：
- 全球快取：你的網站不是只存在於某一台伺服器，而是被複製到世界各地的邊緣節點。
- 自動 SSL：GitHub 默認提供安全的 HTTPS 連線，無需手動管理憑證。
- 極低延遲：美國的用戶從美國節點讀取，台灣用戶從亞洲節點讀取。
1.2 域名解析的奧義 (DNS)
要將自定義域名 (如 www.kql.at) 綁定到 GitHub Pages，理解 DNS 的流向非常重要。
[使用者輸入 www.kql.at]
│
▼
[DNS 伺服器]
│
│ 查詢 CNAME
▼
[你的 DNS 服務商] (如 Cloudflare)
│
│ 指向 your.github.io
▼
[GitHub DNS]
│
│ 解析出真實 IP
▼
[GitHub/Fastly CDN 伺服器]
│
│ 檢查 CNAME 檔案
▼
[你的 Repository] ──▶ [回傳網站內容] ──▶ [使用者]
設定關鍵：
- CNAME 記錄：用於子域名 (如
www)，指向username.github.io。這是最靈活的設置，能自動應對 GitHub IP 的變更。 - A 記錄：用於根域名 (如
kql.at)，直接指向 GitHub 的固定 IP (如185.199.108.153)。
2. 前後端分離：現代開發的標準配置
所謂的「前後端分離」，在 GitHub Pages 的場景下，是指將「前端」視為一個純粹的靜態資源包。
2.1 從源碼到部署
不管你使用 Vue、React 還是其他框架，最終都需要經過「打包 (Build)」的過程。
┌─────────────────────────────┐ ┌──────────────────────────┐
│ 本機開發環境 │ │ 使用者瀏覽器 │
│ │ │ │
│ src/ 源碼 (Vue/React) │ │ 1. 下載 HTML/JS │
│ │ │ │ │ │
│ ▼ npm run build │ │ ▼ │
│ │ deploy │ 2. 瀏覽器執行 JS │
│ dist/ 靜態檔案 ──────────────┼──────────▶│ │ │
│ (index.html, app.js) │ git push │ ▼ │
│ │ │ 3. 渲染 UI 畫面 │
└─────────────────────────────┘ │ │ │
│ ▼ │
│ 4. AJAX 呼叫後端 API │
└────────────┬─────────────┘
│
▼
[你的後端 API]
這意味著 GitHub Pages 完全不需要執行 PHP 或 Node.js，它只需要負責把打包好的 index.html 和 .js 檔案丟給瀏覽器。所有的邏輯運算，都是在「使用者的瀏覽器」中發生的。
3. 安全性大坑：混合內容 (Mixed Content)
當你決定採用這種架構時，有一個絕對無法避開的安全限制。
瀏覽器鐵律：如果你的前端網頁是安全的 (HTTPS)，它嚴格禁止呼叫不安全的後端 (HTTP)。
[使用者瀏覽器 (HTTPS)]
│ │
│ │
❌ 阻擋連線 ✅ 成功連線
│ │
▼ ▼
[HTTP API] [HTTPS API]
(不安全，被擋) (安全，通過)
⚠️ 錯誤訊息：Mixed Content: The page was loaded over HTTPS...
結論：即使你只負責後端，你也必須為你的後端伺服器 (VPS) 配置 SSL 憑證。目前業界標準做法是使用 Let’s Encrypt 搭配 Certbot 進行自動化簽發與續期。
4. 後端架構選擇：「餐廳」經營學
對於後端開發者來說，選擇 VPS、Firebase 還是 Supabase，可以想像成不同類型的「餐飲經營模式」。
方案 A：VPS (自建餐廳)
你自己租店面 (Vultr)、買瓦斯爐、請廚師、申請水電執照。
- 廚房 (DB)：MySQL/MariaDB，你自己安裝、備份。
- 廚師 (API)：你寫的 Node.js/PHP 程式碼，負責把生食煮熟。
- 優勢：極致的自由。你可以隨意更改裝潢，成本固定 (VPS 月費)。
- 劣勢：所有雜事 (SSL 過期、資料庫備份、系統更新) 都要自己來。
方案 B：Firebase (五星級飯店自助餐)
Google 開的連鎖飯店。你不需要廚師，客人 (前端) 直接進廚房拿菜。
- 門禁 (Rules)：門口有高級保全，檢查客人的 ID 卡 (Auth)，決定他能拿什麼菜。
- 特色：
- Real-time：菜盤一空，服務生會從天花板垂降補貨 (WebSocket 即時同步)。
- NoSQL：這裡沒有盤子，食物都是裝在不同形狀的籃子裡 (JSON Document)。
- 劣勢：很難做複雜的點餐 (複雜查詢困難)，且吃到飽真的很貴 (流量計費)。
方案 C：Supabase (模組化現代住宅)
開源界的明日之星，試圖結合兩者優點。
- 核心：它其實就是一座標準的 PostgreSQL 餐廳。
- 魔法：它提供了一個自動翻譯機，把客人的點餐單 (API Request) 直接轉成廚房看得懂的指令 (SQL)。
- Row Level Security (RLS)：這是它的「保全」，你用 SQL 寫規則：「只有訂單主人能看到這張訂單」。
- 優勢：你可以擁有 Firebase 的便利 (不用寫 CRUD API)，但底層依然是強大的關聯式資料庫。
架構決策矩陣
| 特性 | VPS (自架) | Firebase (BaaS) | Supabase (BaaS) |
|---|---|---|---|
| 後端工作量 | 重 (OS, DB, API, SSL) | 輕 (Security Rules) | 中/輕 (Table Schema, RLS) |
| 資料庫類型 | 任意 | NoSQL (文件型) | SQL (關聯式) |
| 前端即時性 | 需自幹 WebSocket | 原生支援 (超強) | 支援 (Realtime) |
| 查詢靈活性 | SQL 說了算 | 弱 (需依賴索引) | SQL 說了算 |
| ** Vendor Lock-in** | 無 (可隨意搬家) | 高 (綁定 Google) | 低 (標準 Postgres) |
5. 成本分析：錢包保衛戰 (附實例試算)
在選擇架構時，除了技術層面，「錢」往往也是決定性因素。這三者的計費邏輯截然不同。
5.1 基本比較
| 項目 | VPS (Vultr/DigitalOcean) | Firebase (Google) | Supabase |
|---|---|---|---|
| 計費模式 | 固定月費 (Flat Rate) | 用量計費 (Pay as you go) | 混合模式 (Tier + Usage) |
| 免費額度 | 無 (通常需付費) | 極高 (Spark Plan) | 普通 (2個專案免費) |
| 爆量風險 | 低 (頂多網站變慢) | 高 (流量大時帳單驚人) | 中 (超過額度需付費) |
| 頻寬限制 | 寬鬆 (通常 1TB 起跳) | 昂貴 ($0.12/GB 起) | 寬鬆 ($0.09/GB, Pro 給 250GB) |
5.2 實戰情境試算
假設你有一個 「中型社群 App」，營運數據如下：
- 日活躍用戶 (DAU)：10,000 人 (蠻成功的產品)
- 使用行為：每人每天瀏覽 100 則貼文 (Reads)，發 2 則貼文 (Writes)
- 資料量：累積 10GB 資料
- 總流量：約 200GB / 月
選手 A：VPS (Vultr Cloud Compute)
- 方案：只需租一台 $6 USD 的機器。
- 運算：足夠應付 10k DAU。
- 流量：內建 1TB – 2TB 流量。
- 總花費：$6 USD / 月 (固定，除非你要升級機器)。
選手 B：Firebase (Blaze Plan)
Firebase 是「用多少算多少」，這時候就很痛了：
- 讀取 (Reads)：10,000 人 * 100 讀取 * 30 天 = 3,000 萬次讀取。
- 價格：($0.06 / 10萬次) * 300 = $18 USD
- 寫入 (Writes)：忽略不計 (相對便宜)。
- 流量 (Bandwidth)：200GB。
- 價格：(200GB – 10GB免費) * $0.12 = $22.8 USD
- 儲存：10GB * $0.18 = $1.8 USD。
- 總花費：約 $42.6 USD / 月 (且隨著用戶增加線性暴增)。
選手 C：Supabase (Pro Plan)
- 方案：Pro Plan 固定費率。
- 費用：$25 USD / 月。
- 包含內容：
- 流量 250GB (我們的 200GB 在範圍內，不用加錢)。
- 資料庫 8GB (我們有 10GB，超額 2GB)。
- 超額費：2GB * $0.125 = $0.25 USD。
- 總花費：約 $25.25 USD / 月。
結論
- 最省：VPS ($6)。只要你技術夠硬，它是最便宜的。
- 最貴：Firebase ($42.6)。雖然初期免費，但只要產品做起來，它的「讀取」和「流量」費用會非常可觀。
- CP 值：Supabase ($25)。比 VPS 貴一點，但省去了維護成本；比 Firebase 便宜且可預測，不會因為用戶狂刷頁面就破產。
6. 總結建議
- 如果你是全端掌控欲強者：繼續使用 VPS。雖然要處理 SSL 很煩，但那種「我知道每行 code 在幹嘛」的安心感無可取代，且成本最可控。
- 如果你想快速驗證產品：Firebase 是最快的，但在資料結構設計上要小心 NoSQL 的坑。
- 如果你討厭寫重複的 API 但需要 SQL：Supabase 是完美的折衷方案，它幫你省去了 CRUD API 和 SSL 的麻煩，同時保留了資料庫的強大。