在過去，應用程序很簡單。瀏覽器向web應用端點發送請求，后者從數據庫中獲取數據并返回響應。

　　移動客戶端的興起以及與其他應用的集成打破了這種簡單性。本文將討論一種處理復雜性的解決方案。

　　增加系統架構的復雜性

　　首先，我們需要對上述簡單的體系結構進行建模。

　　移動客戶端改變了這種方法。移動客戶端的顯示區域更小，例如：平板電腦，手機。

　　有一種可能的解決方案是返回所有數據，并讓每個客戶端過濾掉不必要的數據。不幸的是，手機客戶端也受到帶寬不足的影響，并非所有手機都具備5G功能。即使是這樣，如果它位于偏僻的地方，連接點只能提供H+，那也沒用。

　　因此，不能過度抓取。每個客戶端需要不同的數據子集。使用單體，可以根據每個客戶端提供多個端點。

　　可以設計一個在最前端具有特定層的網絡應用程序，該層檢測發出請求的客戶端，并過濾掉響應中的無關數據，web應用程序中的過度抓取不是問題。

　　如今，微服務風靡一時，每個人及其鄰居都想實現一個微服務架構。

　　微服務背后是“兩個披薩團隊”的理念。每個團隊都是自主的，負責一個微服務或一個前端應用程序。為了避免開發工作之間的耦合，每個微服務團隊發布其API合同并非常謹慎地處理更改。

　　每個微服務都需要為每種客戶端提供嚴格必需的數據，以避免上面的過度抓取問題。對于少量的微服務，讓每個微服務根據客戶端過濾數據很麻煩，數量眾多，這顯然是不可能的，因此，微服務數量與不同客戶端數量之間的笛卡爾因子使得每個微服務上的專用數據端點的成本成倍增長。

　　解決方案：Backend for Front-End

　　BFF背后的想法是將邏輯從每個微服務轉移到一個專用的可部署端點。后者負責：

　　從每個所需的微服務中獲取數據

　　提取相關部分

　　聚合它們

　　最后以一種與特定客戶相關的格式返回

　　同一個團隊開發客戶端及其相關的BFF。BFF提供了與微服務相同的權衡：通過增加系統復雜性來提高開發速度。

　　獨立部署單元與API網關

　　關于BFF的文獻暗示了專用部署單元，如上圖所示。有些文章，比如本篇，反對使用API網關的BFF。但概念圖不一定與部署圖一一對應。

　　與許多領域一樣，人們應該更多地關注組織方而不是技術方面的問題。在這種情況下，最關鍵的一點是，負責前端的團隊也要對BFF負責。無論是單獨的部署單元還是API網關配置的一部分，都是一個實現細節。

　　例如，使用Apache APISIX，每個團隊都可以將他們的BFF代碼獨立部署為單獨的插件。

　　性能考慮

　　對于單體，情況如下：

　　從客戶端到單體的請求需要一個特定的時間T。它經過互聯網，T可能很長。

　　與T相比，對數據庫的不同內部調用可以忽略不計。

　　一旦遷移到微服務，客戶端就需要依次調用每個微服務。因此，對于順序調用，時間變為∑(T1、T2、Ti、Tn)。由于這是不可接受的，客戶端通常使用并行調用。時間變為最大(T1、T2、Ti、Tn)。注意，即使這樣，客戶端也需要執行n個請求。

　　在BFF的情況下，無論實現的是什么，我們都會在T時間內返回一個請求。與單體相比，從BFF到微服務還有額外的請求t1、t2、ti、tn，但它們可能位于一起。因此，整體時間會比單體更長，但由于每個t都比T短得多，因此不會對用戶體驗產生太大影響。

　　結論

　　你可能不應該實現微服務。如果你這樣做，微服務不應該返回整個數據，而是讓客戶端負責清理這些數據。因此，微服務需要根據客戶端返回所需的確切數據。它在微服務與客戶端之間引入了強耦合。

　　你想移除這個耦合。為實現這一點，Backend For Front-end方法將清理邏輯從每個服務中提取到一個專用組件中，該組件還負責聚合數據。每個客戶團隊還負責其專用的BFF：當客戶更改其數據需求時，團隊可以部署適應新需求的新BFF版本。

　　BFF是一個概念解決方案。沒有什么要求提取/清理/聚合邏輯位于特定位置。它可以是專用部署單元，也可以是API網關中的插件。