API后端服務前端的模式介紹

屏幕更小、有限的數據計劃和需要更少請求的移動設備的web體驗與桌面瀏覽器有諸多不同。移動設備需要更少往往也是不同的數據，并且可能提供其它交互，比如通過條形碼掃描器。這意味著我們需要在API后端添加額外的功能，實現對移動設備的支持， Sam Newman 在他的博客文章中如此解釋，并描述了 API后端模式 ，用于處理不同類型用戶體驗設備之間的不匹配。

Thoughtworks的開發者Newman描述了一種解決方案，構建一個通用的API后端，用于所有類型的用戶接口。由于非常不同的需求，雖然在實踐中這意味著向后端增加功能和復雜性。但是它也可能成為瓶頸，因為需要對支持的所有設備部署所需的所有變更，它會減慢部署過程。當從事通用后端開發時，有時需要創建一個特殊團隊，尤其是后端團隊，在Newman看來，這會增加問題，現在前端團隊需要與一個獨立的團隊進行溝通，同時這個團隊還必須優先考慮來自其他團隊的需求。

另一種Newman已經看到在使用的解決方案是為每個用戶體驗開發一個API后端。從概念上來講，一個面向用戶的應用由兩部分組成，一個在客戶端，一個在服務端，也就是服務于前端的后端（BFF這一術語是由SoundCloud的 Phil Cal?ado 創造的）。

BFF通常緊密耦合到一個特定的用戶接口，二者均由同一個團隊維護。當在不同的平臺上處理相同類型的用戶接口時，比如Android和iOS，Newman描述了兩種方法，一種每個平臺一個BFF，另一種是每種類型的接口一個BFF。

Newman更傾向每個平臺一個BFF這種嚴格的模型，比如一個用于Android和一個用于iOS。其中值得關注的是這種方法有在BFF之間產生大量重復工作而結束的風險，比如相同類型的聚合或者為下游服務接口而產生的相似代碼，但是他一點也不擔憂這種重復工作，因為它是跨進程壁壘。合并成一個通用的聚焦邊緣API服務（a general-purpose aggregating Edge API service）是他極力警告和反對的，并指出這種模型已經被一次又一次的證明會導致高度臃腫的代碼。

為每個類型的客戶端使用一個BFF，即Android和iOS共同使用一個BFF，這種方法他看到SoundCloud已經在使用。他對這種方法的顧慮是，隨著越來越多類型的客戶端，增加了BFF臃腫的風險。

同樣為Thoughtworks工作的 Lukasz Plotnicki 最近寫了一篇博客文章，從一體性Rails應用轉向使用微服務期間 SoundCloud所做的BFF工作 。

在 Thoughtworks最新的技術雷達上， BFF 被作為一項值得追求的技術而被提及。

查看英文原文 ： A Pattern for API Backends Serving Frontends

感謝張龍對本文的審校。

給InfoQ中文站投稿或者參與內容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博（@InfoQ，@丁曉昀），微信（微信號： InfoQChina ）關注我們，并與我們的編輯和其他讀者朋友交流（歡迎加入InfoQ讀者交流群 （已滿），InfoQ讀者交流群（#2） ）。