# 微服務架構設計 - Backend For Frontend Pattern (BFF)

# 前言

介紹 BFF 之前我們先講一下 Client 與 Microservices 直接溝通，我們知道微服務有很多的不同的服務，它們的端點也四散在各處，那當今天網頁或是 App 要存取，就要對各自的端點做請求，看似簡單暴力但也衍伸了許多問題，因此現代很少會使用這種溝通方式

# Direct Client-To-Microservices 問題

Client 與服務高耦合
Client 與服務高網路依賴 - 可能造成延遲
服務全都暴露給 Client 的安全性問題
所有接觸 Client 的服務都要做相同的事情，比如驗證

# API Gateway Pattern

由於 Direct Client-To-Microservices 出現了太多問題，後來多數人都使用 API Gateway Pattern 只有單一端口對 Client 開放，有以下特色

反向代理
可做 Redirect 將 Client 與 Microservices 解耦
請求聚合，減少網路溝通成本
通用邏輯都集中在 Gateway 處理

# API Gateway Pattern 問題

儘管 API Gateway Pattern 看似解決了 Direct Client-To-Microservices 很多問題，但還是有很多隱患

產生單點故障問題 - 單一節點故障造成整個系統癱瘓
Client 與 Services 多一層 Gateway 可能造成網路延遲
架構變複雜
需要由專門的團隊來開發與維護 Gateway

# Backend-For-Frontend Pattern

BFF Pattern 就是來解決 API Gateway Pattern 所帶來的問題的
當 Client 的種類越來越多 (手機、網頁、桌面應用程式)，他們都需要單一的端點可能產生一些問題，原因在於每個 Client 所需的格式可能不同 (如 App 需要輕量便捷的設計因此資料結構相較於桌面應用程式簡略)，當然遇到這種問題我們可以對 API Gateway 進行額外處理，但是這樣讓架構變得更複雜也不容易擴展，當有新的 Client 種類就要重新添加

因此後來出現了 BFF Pattern 主要的理念是根據 UX 使用者體驗做 API 切分，也就是說對於不同裝置設置不同的 Proxy Server

# Backend-For-Frontend Pattern 優點

更容易根據 Client 進行調整 API
每個 Proxy 更容易針對 Client 進行發展，容易維護與擴展

理想狀況是每個 Client Dev Team 負責自已的 BFF Proxy，更能對於 Client 進行反應與改變，Backend Team 就只需要針對系統業務進行開發即可

# 參考資料

前端開發者該負責寫 API Endpoints 嗎？The Backend For Frontend Pattern (BFF) In Microservices World

System-Architecture