BFF模式：微服務(wù)前端數(shù)據(jù)加載的最佳實(shí)踐？
設(shè)想一個場景，你需要使用微服務(wù)構(gòu)建電子商務(wù)應(yīng)用程序。你可以為客戶、訂單、產(chǎn)品、購物車等提供微服務(wù)，微服務(wù)暴露 API 給前端使用。
但是，微服務(wù)提供給前端的數(shù)據(jù)可能不會按照前端需要的方式進(jìn)行編排或過濾。
這種情況下，前端需要一些邏輯來重新處理這些數(shù)據(jù)，同時在用戶端使用這樣的邏輯會占用更多的瀏覽器資源。
在這樣的情況下，我們可以使用 BFF 將一些前端邏輯轉(zhuǎn)移到中間層，中間層就是 BFF。當(dāng)前端請求一些數(shù)據(jù)時，它將調(diào)用 BFF 中的 API。
BFF 將執(zhí)行以下操作：
調(diào)用相關(guān)的微服務(wù) API 并獲取所需數(shù)據(jù)
根據(jù)前端展現(xiàn)來處理數(shù)據(jù)
將格式化后的數(shù)據(jù)發(fā)送到前端
因此，前端將有更少的邏輯，BFF 有助于簡化數(shù)據(jù)展示，并為前端提供一個目的明確的接口。
下圖顯示了每個微服務(wù)如何通過 BFF 與前端連接。
正如我們已經(jīng)探討過的，BFF 充當(dāng)前端和微服務(wù)之間的簡單接口。理想情況下，前端團(tuán)隊也將負(fù)責(zé)管理 BFF。
一個 BFF 只關(guān)注一個 UI，而且只關(guān)注那個 UI。因此，它將幫助我們保持前端的簡單性，并通過后端輸出的統(tǒng)一的數(shù)據(jù)格式。
這就引出了下一個問題。我們能為多個用戶界面提供多個 BFF 嗎？我們將在后面回答這個問題。
現(xiàn)在我們知道 BFF 類似于客戶端和其他外部 API、服務(wù)等之間的代理服務(wù)器。如果請求必須通過另一個組件，它肯定會增加延遲。但是，如果瀏覽器需要處理多個未針對前端優(yōu)化的服務(wù)，那么與瀏覽器的高資源使用率相比，BFF 延遲可以忽略不計。
構(gòu)建 BFF 允許你智能地對其他后端 / 微服務(wù)進(jìn)行批處理調(diào)用，并一次返回所有數(shù)據(jù)，或者通過轉(zhuǎn)換和格式化數(shù)據(jù)來返回更方便的展現(xiàn)形式。
這對于 2G 或 3G 網(wǎng)絡(luò)上的移動客戶端非常有用，因為在這些網(wǎng)絡(luò)上建立連接可能需要幾秒鐘（或更長時間）。
與許多其他模式一樣，在應(yīng)用程序中使用 BFF 取決于你計劃遵循的上下文和體系結(jié)構(gòu)。如果你的應(yīng)用程序是一個簡單的單片應(yīng)用程序（譯者注：monolithic app，單片軟件指非模塊化的軟件，也是一種設(shè)計思想。它將 UI、數(shù)據(jù)、邏輯等全部做成一整塊，以一個完全整體的方式實(shí)現(xiàn)，通常會直接從開始到結(jié)束完成一個復(fù)雜任務(wù)的每一小步，同時由自己獨(dú)立對所有的數(shù)據(jù)進(jìn)行管理，更多可見 https://www.zhihu.com/question/37905345/answer/75170829），那么 BFF 是不必要的，它幾乎毫無價值。
但是，如果你的應(yīng)用程序依賴于微服務(wù)，并且使用許多外部 API 和其他服務(wù)，那么最好使用 BFF 來簡化數(shù)據(jù)流，并為你的應(yīng)用程序帶來更高的效率。
此外，如果你的應(yīng)用程序需要為特定的前端接口開發(fā)優(yōu)化的后端，或者你的客戶端需要使用在后端進(jìn)行大量聚合的數(shù)據(jù)，那么 BFF 是一個合適的選項。
提示：分布式設(shè)計需要不同種類的代碼協(xié)作工具。使用 Bit（Github）在單個組件上進(jìn)行協(xié)作，這些組件可以跨代碼倉庫共享并獨(dú)立開發(fā)。
保持你的代碼倉庫可擴(kuò)展性、可維護(hù)性和始終同步。
了解更多信息：
如何構(gòu)建微前端：
https://blog.bitsrc.io/how-we-build-micro-front-ends-d3eeeac0acfc?fileGuid=S9EhcQ4jbascxSJk
如何利用 Bit 在微服務(wù)間共享和重用代碼：
https://blog.bitsrc.io/how-we-successfully-share-and-reuse-code-between-microservices-at-scale-20fcfaebc6d0?fileGuid=S9EhcQ4jbascxSJk
當(dāng)然可以！這就是 BFF 的意義所在。
沒有 BFF 的傳統(tǒng)應(yīng)用程序?qū)τ诟鞣N客戶端只有一個 API 網(wǎng)關(guān)，如下所示，
來源：https://perspectives.mobilelive.ca/
然而，擁有 BFF 的目的是為客戶端提供一個可連接的集中接口。例如，移動 UI 的數(shù)據(jù)消耗可能不同于瀏覽器的數(shù)據(jù)消耗。在這種情況下，為了更好地展示數(shù)據(jù)，可以使用兩個 BFF。多個 BFF 的應(yīng)用程序如下圖所示，
來源：https://perspectives.mobilelive.ca/
如你所見，每種客戶端都有一個 BFF，它將有助于優(yōu)化服務(wù)（Sa、Sb…Sn）的響應(yīng)。
擁有 BFF 的幾個優(yōu)點(diǎn)，
關(guān)注點(diǎn)分離——前端需求將與后端關(guān)注點(diǎn)分離，便于維護(hù)。
更容易維護(hù)和修改 API——客戶端應(yīng)用程序?qū)?API 結(jié)構(gòu)了解較少，這將使其對 API 中的更改更有彈性。
更好的前端錯誤處理——大部分時間，服務(wù)器錯誤對前端用戶是沒有意義的。BFF 可以映射出需要顯示給用戶的錯誤，而不是直接返回服務(wù)器錯誤，這將改善用戶體驗。
多種設(shè)備類型可以并行調(diào)用后端——當(dāng)瀏覽器向 BFF 發(fā)出請求時，移動設(shè)備也可以這樣做。這將有助于更快地獲得相應(yīng)服務(wù)的響應(yīng)。
更好的安全性——某些敏感信息可以被隱藏，并且在向前端返回響應(yīng)時可以忽略不必要的數(shù)據(jù)。這種抽象將使攻擊者更難以應(yīng)用程序為目標(biāo)。
共享組件的團(tuán)隊所有權(quán)——應(yīng)用程序的不同部分可以由不同的團(tuán)隊輕松處理。前端團(tuán)隊可以共享客戶端應(yīng)用程序及其底層資源消耗層的所有權(quán)，從而提高開發(fā)速度。下圖顯示了團(tuán)隊劃分 BFF 的例子。
來源：https://samnewman.io/patterns/architectural/bff/
到目前為止，我們所看到的一切都是驚人的！但是，BFF 是否可以防故障？
答案是否定的！和其他技術(shù)或模式一樣，即使是 BFF 也有陷阱。為了避免這些，我們必須遵循一些最佳實(shí)踐。下面列出了一些要遵循的最佳做法。
避免使用自包含的大而全的 API 實(shí)現(xiàn) BFF——你的自包含 API 應(yīng)該位于微服務(wù)層。大多數(shù)開發(fā)人員忘記了這一點(diǎn)，也開始在 BFF 中實(shí)現(xiàn)服務(wù)級別 API。你應(yīng)該記住，BFF 是客戶端和服務(wù)之間的轉(zhuǎn)換層。當(dāng)數(shù)據(jù)從服務(wù)端 API 返回時，其目的是將其轉(zhuǎn)換為客戶端應(yīng)用程序指定的數(shù)據(jù)類型。
避免 BFF 邏輯重復(fù)——需要注意的一個關(guān)鍵點(diǎn)是，單個 BFF 應(yīng)該滿足特定的用戶體驗，而不是設(shè)備類型。例如，大多數(shù)時候，所有移動設(shè)備（iOS、Android 等）共享相同的用戶體驗。在這種情況下，所有這些操作系統(tǒng)的一個 BFF 就足夠了。iOS 不需要單獨(dú)的 BFF，Android 也不需要單獨(dú)的 BFF。
避免過度依賴 BFF——BFF 只是一個轉(zhuǎn)換層。是的，它也為應(yīng)用程序提供了一定程度的安全性。但是，你不應(yīng)該過分依賴它。你的 API 層和前端層應(yīng)該負(fù)責(zé)所有的功能和安全方面，而不管是否存在 BFF。因為 BFF 只是填補(bǔ)一個空白，而不是向應(yīng)用程序添加任何功能或服務(wù)。
BFF 模式不僅有助于開發(fā)，而且有助于極大地改善用戶體驗。因此，在保持 BFF 專注于其前端的同時，考慮數(shù)據(jù)優(yōu)化和聚合是非常重要的。
此外，如果你以前沒有使用過 BFF 模式，現(xiàn)在是時候開始了。
https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-introduction-e4fa965128bf
最后
歡迎加我微信(winty230)，拉你進(jìn)技術(shù)群，長期交流學(xué)習(xí)...
歡迎關(guān)注「前端Q」,認(rèn)真學(xué)前端，做個專業(yè)的技術(shù)人...
