BFF (Backend for Frontend) 模式

隨著系統的成長，「一體適用 (One Size Fits All)」的 API Gateway 可能會成為瓶頸。BFF (Backend for Frontend) 模式為複雜的多客戶端應用程式提供了解決方案。

問題：多樣化的客戶端

想像你有兩個客戶端：

行動 App：需要小的 Payload（為了節省數據/電池）。需要顯示簡單的「訂單摘要」。

網頁儀表板：需要巨大的 Payload（頻寬很便宜）。需要顯示複雜的「帶有分析的訂單歷史」。

如果您只有一個通用 API /orders，您必須妥協：

要嘛發送太多資料給行動裝置（臃腫）。

要嘛發送太少資料給網頁（迫使它進行 10 次額外的呼叫）。

與其使用一個通用 API Gateway，不如為每種客戶端類型建立特定的入口點 (BFFs)。

Mobile BFF：呼叫底層微服務（使用者、訂單、庫存），將資料縫合成專為 iOS 螢幕設計的緊湊 JSON，並將其發送回去。

Web BFF：呼叫相同的微服務，但彙總專為桌面視圖設計的詳細資料。

最佳化體驗：API 完美匹配 UI 需求。沒有過度獲取 (over-fetching) 或獲取不足 (under-fetching)。

團隊自主權：行動團隊可以編寫自己的 BFF 程式碼（例如，用 Node.js）來完全按照他們想要的方式格式化資料，而無需等待後端團隊更改核心微服務。

封裝：如果行動 App 需要特定的舊身份驗證流程，它會保留在 Mobile BFF 中，而不會污染核心系統。

直接方法：Mobile -> 微服務（壞：緊密耦合）。

Gateway 方法：Mobile -> Gateway -> 微服務（較好：單一入口）。

BFF 方法：Mobile -> Mobile BFF -> 微服務（最適合複雜 API）。

當您有多個不同的客戶端類型（行動、網頁、電視、手錶）且資料需求截然不同時。

當您的 UI 團隊被後端團隊阻礙時。

一體適用 的 API 通常會導致行動裝置上的過度獲取或網頁上的獲取不足。

BFF 為每個特定的使用者介面建立專用的 API 層，最佳化性能和開發人員自主權。

下一步：Gateway 章節到此結束！讓我們在章節總結中回顧所有內容。