英文 | https://medium.com/frontend-at-scale/frontend-architectural-patterns-backend-for-frontend-29679aba886c
譯文 | https://www.toutiao.com/i6881171438959591944/
它是什麼?
後端到後端的體系結構模式描述了一個世界，其中每個用戶端應用程式都有自己的伺服器端元件-特定前端的後端。
如果您有多個具有完全不同需求且都消耗相同基礎資源的用戶端接口，則此模式非常适用。現實世界中最常見的示例是同時具有Web和移動用戶端的應用程式。
要了解為什麼"後端對前端"有用，讓我們逐漸了解一下網絡體系結構的一些發展。
單個通用伺服器上有多個用戶端
> Monolithic application with multiple clients (source: author)
簡單就好吧? 實際上，這隻是……但僅限于某一點。如果您的應用程式足夠小，則此體系結構絕對可以正常工作! 但是，整料傾向于随尺寸分解。您可能會聽到您的團隊開始說類似……
- 我們的伺服器太臃腫了! 特定于客戶的控制流随處可見，我們正在努力添加功能而不引入副作用。
- 沒有合并沖突，我無法送出任何更改。N個團隊正在更改此确切的代碼。一些我們幾乎不交談的東西!
- 建構和測試将永遠運作，而調試一次間歇性的測試失敗将需要幾天的時間。
這些類型的問題催化了微服務的興起。
具有微服務架構的多個用戶端
> Microservices! (source: author)
如果在适當的範圍内實施微服務，那麼微服務非常适合擴充規模并有助于解決一系列問題。
- 後端團隊通常負責一項服務，而不再互相絆倒。
- 單個微服務是輕量級的，可定制的，分離的，并且易于擴充。
但是，前端團隊之間仍然存在邊界問題。處理多個用戶端的職責仍然編碼在一項或多項服務中。前端工程師正在努力将多個用例塞入一個API層，并且客戶體驗開始受到影響。網絡團隊和移動團隊之間的緊張關系正在加劇。
為什麼我們不能像對待微服務一樣，圍繞不同的客戶劃定技術群組織界限?
具有專用後端和微服務架構的多個用戶端
> BFF! (source: author)
輸入後端換前端! 我們利用這樣的事實，即我們的客戶有不同的需求來劃定有用的界限。BFF應用程式是輕量級轉換層，可将單個用戶端與下遊服務分離開來，并且僅服務于一個前端。
BFF的好處
- 前端團隊可以享受其用戶端應用程式及其底層資源消耗層的所有權; 導緻高速發展。
- 移動團隊最終能夠進行更改，例如有效載荷大小和降低頻率，而不必擴充和派發最初為基于Web的用例開發的API。
- 用戶端應用程式隻需要知道一個資源伺服器-封裝規則!
- BFF是特定于客戶的，一維的且與語言無關。選擇正确的API技術從未如此簡單。
- 用戶端應用程式受到保護，免受下遊服務中API的更改。
- 網絡和移動團隊不再為誰首先合并以及誰必須處理合并沖突而戰。
TL; DR，如果…，則使用BFF
- 您有多個具有不同需求的用戶端正在使用相同的基礎資源。
- 您希望基于每個用戶端優化後端API，資料處理或技術堆棧。
- 您的客戶需要使用需要大量後端聚合的資料。
- 開發團隊在功能傳遞方面存在沖突，可以從增加的自主權中受益。
…但請確定避免這些陷阱
- 跨BFF複制邏輯。複制代碼是同一代碼的多個執行個體，這些執行個體解決了相同的用例，并且将經曆相同的更改。例如，執行特定的業務規則。
- 不遵循良好的DevOps慣例。更多的後端意味着更多的可部署服務和增加的操作複雜性。
- 無意間将您的BFF轉換為功能完善的API伺服器，其中包含業務邏輯，資料庫，安全性和廚房接收器。保持BFF輕巧，并專注于主要用例：高效地将資料轉換為客戶。
- 無法識别或調整您的BFF是單點故障的事實。您的BFF可能會與許多服務通信的事實意味着任何下遊服務的故障都可能傳播到您的BFF。考慮使用備援和異步性來解決這些問題，就像使用其他類型的微服務一樣。
本文完~