BFF 模式：微服務前端數據加載的最佳實踐？

譯者｜吳留坡

這種情況下，前端需要一些邏輯來重新處理這些數據，同時在用戶端使用這樣的邏輯會佔用更多的瀏覽器資源。

BFF 將執行以下操作：

下圖顯示了每個微服務如何通過 BFF 與前端連接。

正如我們已經探討過的，BFF 充當前端和微服務之間的簡單接口。理想情況下，前端團隊也將負責管理 BFF。

構建 BFF 允許你智能地對其他後端 / 微服務進行批處理調用，並一次返回所有數據，或者通過轉換和格式化數據來返回更方便的展現形式。

應用程序何時使用 BFF

但是，如果你的應用程序依賴於微服務，並且使用許多外部 API 和其他服務，那麼最好使用 BFF 來簡化數據流，併爲你的應用程序帶來更高的效率。

此外，如果你的應用程序需要爲特定的前端接口開發優化的後端，或者你的客戶端需要使用在後端進行大量聚合的數據，那麼 BFF 是一個合適的選項。

提示：分佈式設計需要不同種類的代碼協作工具。使用 Bit（Github）在單個組件上進行協作，這些組件可以跨代碼倉庫共享並獨立開發。

保持你的代碼倉庫可擴展性、可維護性和始終同步。

瞭解更多信息：

如何構建微前端：
https://blog.bitsrc.io/how-we-build-micro-front-ends-d3eeeac0acfc?fileGuid=S9EhcQ4jbascxSJk
如何利用 Bit 在微服務間共享和重用代碼：
https://blog.bitsrc.io/how-we-successfully-share-and-reuse-code-between-microservices-at-scale-20fcfaebc6d0?fileGuid=S9EhcQ4jbascxSJk

我們能有多個 BFF 嗎？

當然可以！這就是 BFF 的意義所在。

沒有 BFF 的傳統應用程序對於各種客戶端只有一個 API 網關，如下所示，

來源：https://perspectives.mobilelive.ca/

然而，擁有 BFF 的目的是爲客戶端提供一個可連接的集中接口。例如，移動 UI 的數據消耗可能不同於瀏覽器的數據消耗。在這種情況下，爲了更好地展示數據，可以使用兩個 BFF。多個 BFF 的應用程序如下圖所示，

來源：https://perspectives.mobilelive.ca/

如你所見，每種客戶端都有一個 BFF，它將有助於優化服務（Sa、Sb…Sn）的響應。

BFF 的優點

擁有 BFF 的幾個優點，

關注點分離——前端需求將與後端關注點分離，便於維護。
更容易維護和修改 API——客戶端應用程序對 API 結構瞭解較少，這將使其對 API 中的更改更有彈性。
更好的前端錯誤處理——大部分時間，服務器錯誤對前端用戶是沒有意義的。BFF 可以映射出需要顯示給用戶的錯誤，而不是直接返回服務器錯誤，這將改善用戶體驗。
多種設備類型可以並行調用後端——當瀏覽器向 BFF 發出請求時，移動設備也可以這樣做。這將有助於更快地獲得相應服務的響應。
更好的安全性——某些敏感信息可以被隱藏，並且在向前端返回響應時可以忽略不必要的數據。這種抽象將使攻擊者更難以應用程序爲目標。
共享組件的團隊所有權——應用程序的不同部分可以由不同的團隊輕鬆處理。前端團隊可以共享客戶端應用程序及其底層資源消耗層的所有權，從而提高開發速度。下圖顯示了團隊劃分 BFF 的例子。

在實踐中遵循的最佳實踐

避免使用自包含的大而全的 API 實現 BFF——你的自包含 API 應該位於微服務層。大多數開發人員忘記了這一點，也開始在 BFF 中實現服務級別 API。你應該記住，BFF 是客戶端和服務之間的轉換層。當數據從服務端 API 返回時，其目的是將其轉換爲客戶端應用程序指定的數據類型。
避免 BFF 邏輯重複——需要注意的一個關鍵點是，單個 BFF 應該滿足特定的用戶體驗，而不是設備類型。例如，大多數時候，所有移動設備（iOS、Android 等）共享相同的用戶體驗。在這種情況下，所有這些操作系統的一個 BFF 就足夠了。iOS 不需要單獨的 BFF，Android 也不需要單獨的 BFF。
避免過度依賴 BFF——BFF 只是一個轉換層。是的，它也爲應用程序提供了一定程度的安全性。但是，你不應該過分依賴它。你的 API 層和前端層應該負責所有的功能和安全方面，而不管是否存在 BFF。因爲 BFF 只是填補一個空白，而不是嚮應用程序添加任何功能或服務。

總結

BFF 模式不僅有助於開發，而且有助於極大地改善用戶體驗。因此，在保持 BFF 專注於其前端的同時，考慮數據優化和聚合是非常重要的。

此外，如果你以前沒有使用過 BFF 模式，現在是時候開始了。