Day 5 | 🧬 架構的演進：從單體式到前後端分離

嗨，各位鐵人夥伴！ 👋

這是一篇專為新手設計的文章。如果你是經驗豐富的老手，可以跳過這篇，或者把它分享給你沒時間親自指導的新人，解放你的寶貴時間！ 😉

本文會用最淺顯易懂的方式，從單體式架構，到前後端分離，再演進到 Isomorphic JavaScript (Universal JavaScript)，讓完全沒有基礎的讀者也能輕鬆理解。

🌐 基礎知識：HTTP 請求 (Request) 與回應 (Response)

我們的討論將以 Web 應用系統為主，其核心通訊協定就是 HTTP 或 HTTPS。運作的關鍵概念是：請求 (Request) 與 回應 (Response)。

當使用者透過瀏覽器訪問你的網站時，會發起一個 HTTP 請求 (HTTP Request) 送到你的伺服器。這個請求通常包含：

• 方法 (Method)：例如 GET、POST，說明這次請求的意圖。
• URL：目標網址。
• 請求標頭 (Headers)：夾帶瀏覽器資訊等額外資料。
• 請求主體 (Body)：若需要傳送資料給伺服器，會放在這裡。

伺服器接收到請求後，會根據你寫好的邏輯，回傳一個 HTTP 回應 (HTTP Response)。這個回應通常包含：

• 狀態碼 (Status Code)：告知瀏覽器處理結果，例如 200 表示成功，404 表示找不到頁面。
• 回應標頭 (Headers)：說明回應的內容類型等資訊。
• 回應主體 (Body)：伺服器回傳的實際內容，可以是純文字、完整的 HTML 頁面、JSON 資料或檔案。

🔗 前後端分離與客戶端渲染 (CSR)

延續前一章節提到的前端與後端技術，你應該已經有了基本概念。那「分離」是什麼意思呢？

簡單來說，就是將程式碼分成兩包，讓它們可以：

• 獨立開發：前端與後端工程師可以依據 API 規格分頭進行，互不干擾。
• 獨立部署：前端可以部署在 A 主機，後端部署在 B 主機，並可根據各自的負載需求獨立進行擴展 (Scale-out)。

既然前後端分家了，它們如何協作呢？這就要談到 客戶端渲染 (Client-Side Rendering, CSR) 的運作方式：

1. 瀏覽器發出初始請求：使用者初次訪問網站時，瀏覽器向前端伺服器發出請求。
2. 前端伺服器回傳空殼 HTML：前端伺服器僅回傳一個極輕量的 HTML 檔案，裡面包含了載入主要 JavaScript 檔案的標籤。
3. 瀏覽器執行 JavaScript：瀏覽器下載並執行 JavaScript，這支程式碼會向後端伺服器發送 API 請求以獲取資料。
4. 後端伺服器回傳資料：後端專注於業務邏輯與資料庫操作，並以 JSON 格式回傳純資料。
5. 瀏覽器渲染最終頁面：瀏覽器的 JavaScript 收到 JSON 資料後，動態地在本地產生完整的 HTML 內容，最終呈現給使用者。

💡 前後端分離是一種「架構模式」，而 CSR 是一種實現該架構的「渲染手段」。

🧱 單體式架構 (Monolithic Architecture)

「太麻煩了！我只是想快速寫個公司內部系統，還要學前端框架？」

如果這也是你的心聲，那單體式架構可能適合你。如同其名，單體式架構就是將 HTML、CSS、JavaScript 以及後端程式碼（如 Java、Python）全部打包在一個專案中，一起開發、一起部署。

你可能會想：「等等，HTML/CSS/JS 不是應該在瀏覽器執行嗎？」

沒錯！在單體架構中，它們的運作方式如下：

1. 發送 Request：瀏覽器發出請求給你的伺服器。
2. 後端處理與渲染：後端程式碼處理所有業務邏輯、查詢資料庫，並在伺服器端 (Server-Side) 直接產生出一個完整的 HTML 頁面。這個過程也常被稱為伺服器端渲染 (Server-Side Rendering, SSR)。
3. 一次性回傳：這個完整的 HTML 頁面，連同所有需要的 CSS 和 JavaScript，會被一次性地打包成 Response 回傳給瀏覽器。
4. 瀏覽器顯示：瀏覽器收到後就能直接顯示最終畫面，不需再額外發送 API 請求。

你可能會問：「聽起來很棒啊？為什麼大家不都用這個架構？」

事實上，Web 應用的趨勢是從單體式架構走向前後端分離。主要原因在於單體架構有幾個明顯的缺點：

• ** 使用者體驗不佳**：每次頁面切換，伺服器都必須重新渲染並回傳整個頁面，容易造成肉眼可見的「換頁閃爍」。
• ** 開發與協作困難**：隨著軟體功能日趨複雜，專業分工變得重要。前後端分離讓團隊可以並行開發，提升效率，這是角度問題，也有人認為小專案一包開發更快，因情況而異。
• ** 擴展性差**：當特定功能流量暴增時，你無法獨立擴展該功能，只能升級整個伺服器硬體，成本高且缺乏彈性。

當然，它也有優點：

• 👍 優點：開發流程單純，一個專案搞定所有事，對於小型或內部系統來說，維護相對簡單。

📈 SSR 與搜尋引擎優化 (SEO)

單體架構（或說 SSR）有一個至今仍無法被完全取代的關鍵優勢：SEO (Search Engine Optimization)。

Google 的爬蟲程式會抓取網站內容來建立索引。如果你的網站對爬蟲不友善，在搜尋結果中的排名就會很低。

• SSR 的優勢：當爬蟲訪問你的網站時，伺服器會直接回傳一個內容完整的 HTML 頁面。爬蟲可以立刻讀取到所有關鍵字與內容，對 SEO 非常有利。
• CSR 的挑戰：CSR 頁面在初始載入時是一個空殼，需要等待 JavaScript 執行後才去 API 拉取資料並渲染。雖然人眼幾乎感受不到延遲，但爬蟲不一定會等待，可能只抓取到空蕩蕩的頁面，導致 SEO 效果不佳。

業界共識是，有 SEO 需求的頁面（如商品頁、部落格文章），最保險的做法就是採用 SSR。沒人敢拿產品的搜尋排名開玩笑！

✨ 兩全其美：Isomorphic JavaScript (Universal JavaScript)

有沒有辦法，既能享受 SSR 的 SEO 優勢，又能擁有 CSR 的流暢互動體驗與獨立開發的好處呢？

答案是肯定的，這要歸功於 Node.js 的出現。

Node.js 讓 JavaScript 不僅能在瀏覽器執行，也能在伺服器執行。這種「一套語言，通吃前後端」的能力，催生了如 Next.js、Nuxt.js 等現代前端框架。

這些框架賦予開發者極大的彈性，可以為不同頁面選擇最適合的渲染模式：

• 伺服器端渲染 (SSR)

  • 優勢：首頁載入快，SEO 效果極佳。
  • 適用場景：官網首頁、部落格文章、產品列表頁等需要被搜尋引擎快速索引的公開頁面。

• 客戶端渲染 (CSR)

  • 優勢：頁面互動性強，使用者體驗流暢，無需頻繁刷新頁面。
  • 適用場景：後台管理系統、會員中心、購物車等重互動、無需 SEO 的內部頁面。

這種讓同一份 JavaScript 程式碼能根據需求，選擇在伺服器或瀏覽器執行的技術，就被稱為 Isomorphic JavaScript (或 Universal JavaScript)。它完美地結合了兩種渲染模式的優點，讓我們能打造出既有良好 SEO、又具備極致使用者體驗的現代化應用程式。

✨ 小結論

其實甲方三種架構你都看得到，當然這包含了眾多因素在裡面，我在甲方看過單純CSR的前後端分離，單體架構，Universal JavaScript(CSR SSR混合)，你或許還會聽到微服務架構(這比較難，我們在後面會很簡單的帶到)，我個人認為， 不必認為誰一定優誰一定劣，調整好自己的心態比較重要