前端架構模式：支持前端的后端
英文 |?https://medium.com/frontend-at-scale/frontend-architectural-patterns-backend-for-frontend-29679aba886c
譯文 |?https://www.toutiao.com/i6881171438959591944/
它是什么?
后端到后端的體系結構模式描述了一個世界，其中每個客戶端應用程序都有自己的服務器端組件-特定前端的后端。
如果您有多個具有完全不同需求且都消耗相同基礎資源的客戶端接口，則此模式非常適用。現(xiàn)實世界中最常見的示例是同時具有Web和移動客戶端的應用程序。
要了解為什么"后端對前端"有用，讓我們逐步了解一下網(wǎng)絡體系結構的一些發(fā)展。
單個通用服務器上有多個客戶端
> Monolithic application with multiple clients (source: author)
我們的服務器太臃腫了! 特定于客戶的控制流隨處可見，我們正在努力添加功能而不引入副作用。 沒有合并沖突，我無法提交任何更改。N個團隊正在更改此確切的代碼。一些我們幾乎不交談的東西! 構建和測試將永遠運行，而調試一次間歇性的測試失敗將需要幾天的時間。
具有微服務架構的多個客戶端
> Microservices! (source: author)
如果在適當?shù)姆秶鷥葘嵤┪⒎眨敲次⒎辗浅＿m合擴展規(guī)模并有助于解決一系列問題。
后端團隊通常負責一項服務，而不再互相絆倒。
單個微服務是輕量級的，可定制的，分離的，并且易于擴展。
但是，前端團隊之間仍然存在邊界問題。處理多個客戶端的職責仍然編碼在一項或多項服務中。前端工程師正在努力將多個用例塞入一個API層，并且客戶體驗開始受到影響。網(wǎng)絡團隊和移動團隊之間的緊張關系正在加劇。
為什么我們不能像對待微服務一樣，圍繞不同的客戶劃定技術和組織界限?
具有專用后端和微服務架構的多個客戶端
> BFF! (source: author)
輸入后端換前端! 我們利用這樣的事實，即我們的客戶有不同的需求來劃定有用的界限。BFF應用程序是輕量級轉換層，可將單個客戶端與下游服務分離開來，并且僅服務于一個前端。
BFF的好處
前端團隊可以享受其客戶端應用程序及其底層資源消耗層的所有權; 導致高速發(fā)展。
移動團隊最終能夠進行更改，例如有效載荷大小和降低頻率，而不必擴展和派發(fā)最初為基于Web的用例開發(fā)的API。
客戶端應用程序只需要知道一個資源服務器-封裝規(guī)則!
BFF是特定于客戶的，一維的且與語言無關。選擇正確的API技術從未如此簡單。
客戶端應用程序受到保護，免受下游服務中API的更改。
網(wǎng)絡和移動團隊不再為誰首先合并以及誰必須處理合并沖突而戰(zhàn)。
您有多個具有不同需求的客戶端正在使用相同的基礎資源。
您希望基于每個客戶端優(yōu)化后端API，數(shù)據(jù)處理或技術堆棧。
您的客戶需要使用需要大量后端聚合的數(shù)據(jù)。
開發(fā)團隊在功能交付方面存在沖突，可以從增加的自主權中受益。
…但請確保避免這些陷阱
跨BFF復制邏輯。復制代碼是同一代碼的多個實例，這些實例解決了相同的用例，并且將經(jīng)歷相同的更改。例如，執(zhí)行特定的業(yè)務規(guī)則。
不遵循良好的DevOps慣例。更多的后端意味著更多的可部署服務和增加的操作復雜性。
無意間將您的BFF轉換為功能完善的API服務器，其中包含業(yè)務邏輯，數(shù)據(jù)庫，安全性和廚房接收器。保持BFF輕巧，并專注于主要用例：高效地將數(shù)據(jù)轉換為客戶。
無法識別或調整您的BFF是單點故障的事實。您的BFF可能會與許多服務通信的事實意味著任何下游服務的故障都可能傳播到您的BFF。考慮使用冗余和異步性來解決這些問題，就像使用其他類型的微服務一樣。
本文完~
