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