BFF全稱是Backends For Frontends(服務于前端的後端)，Sam Newman曾在他的部落格中寫了一篇相關的文章——Pattern: Backends For Frontends，在文章中Sam Newman詳細地說明了BFF。
BFF就是伺服器設計API時會考慮到不同裝置的需求，也就是為不同的裝置提供不同的API接口，雖然它們可能是實作相同的功能，但因為不同裝置的特殊性，它們對服務端的API通路也各有其特點，需要差別處理。是以出現了類似下圖一種設計方式。
用戶端都不是直接通路伺服器的公共接口，而是調用BFF層提供的接口，BFF層再調用基層的公共服務，不同的用戶端擁有不同的BFF層，它們定制用戶端需要的API。圖一和圖二的不同之處在于是否需要為相似的裝置人，如IOS和android分别提供一個BFF，這個需要根據現實情況決定，不同的項目環境解決手段不一樣。
那麼采用BFF架構與多端公用、單一的API有什麼優點了？最重要的一點在上文中已經提到了，它能夠滿足因不同用戶端特殊的互動引起的對新接口的要求，是以一開始就會針對相應的裝置設計好對應的接口。如果使用單一、通用的API，我們一開始并沒有考慮到特殊需求，那麼有新的請求需要出現時，可能會出現以下問題：
如果添加新的接口，這樣容易造成接口的不穩定
如果考慮在原有的接口上進行修改，可能需要會産生一些的耦合，破壞單一職責
考慮這樣一個簡單例子，因為移動APP的螢幕限制，在某一個清單頁我們隻需要展示一些關鍵的資訊，但是由于調用的是服務端提供統一的API，服務端在設計的時候隻考慮到了web端，傳回所有的字段資訊，但這些對于移動端而言都是無用的。在優化性能時處理這樣的問題時，伺服器端就需要新增接口或者通過引入相關耦合來解決這樣的問題。而使用BFF在很大程度能避免這樣的問題。
使用BFF的另一個優點就是當由于某一用戶端需要調用調用多個不同的服務端接口來實作某一功能時，可以直接在對應的BFF層編寫相應的API，而不會影響到基層的公共服務，且用戶端不用直接向多個背景發起調用，可以優化性能。
當然，凡事有利有弊，BFF帶來便利好處的同時也會引起一些問題，如代碼重複，加大開發工作量等。是以在使用時需要結合現實情況仔細斟酌，符合項目的應用開發背景。例如螞蟻财富使用BFF的場景如下。