本文主要内容：
什麼是 BFF
BFF 解決了什麼問題
使用 BFF 的正确姿勢
實戰中的玩法
BFF，即 Backend For Frontend（服務于前端的後端），也就是伺服器設計 API 時會考慮前端的使用，并在服務端直接進行業務邏輯的處理，又稱為使用者體驗擴充卡。BFF 隻是一種邏輯分層，而非一種技術，雖然 BFF 是一個新名詞，但它的理念由來已久。
如下圖，在我們的前端頁面時常存在，某個頁面需要向 backend A、backend B 以及 backend C...... 發送請求，不同服務的傳回值用于渲染頁面中不同的 component，即一個頁面存在很多請求的場景。
此時，每次通路該頁面都需要發送 3 個請求。同時為了保障 Android，iOS，以及 Web 端的不同需求，需要為不同的平台寫不同的 API 接口，而每當值發生一些變化時，需要 Android，iOS，Web 做出修改。與此同時，當我們需要對一個字元串進行處理，如限定 140 個字元的時候，我們需要在每一個用戶端（Android，iOS，Web）分别實作一遍，這樣的代價顯然相當大。
于是，我們就需要 BFF 作為中間件。在這個中間件上我們将做一些業務邏輯處理：
而當我們有了 BFF 這一層時，我們就不需要考慮系統後端的遷移。後端發生的變化都可以在 BFF 層做一些響應的修改。
例如，我們加入 BFF 層，原本每次通路發送 3 請求頁面，變成一個請求。
多端應用 我們在設計 API 時會考慮到不同裝置的需求，也就是為不同的裝置提供不同的 API，雖然它們可能是實作相同的功能，但因為不同裝置的特殊性，它們對服務端的 API 通路也各有其特點，需要差別處理。
服務聚合 随着微服務的興起，原本在同一個程序内運作的業務流程被拆分到了不同的服務中。這在增加業務靈活性的同時，也讓前端的調用變得更複雜。BFF 的出現為前端應用提供了一個對業務服務調用的聚合點，它屏蔽了複雜的服務調用鍊，讓前端可以聚焦在所需要的資料上，而不用關注底層提供這些資料的服務。
非必要，莫新增 我們在看到 BFF 帶來的各種好處的同時，也要注意到它所帶來的代碼重複和工作量增加方面的問題。如果與已有 BFF 功能類似，且展現資料的要求也相近的話，一定要謹慎對待新增 BFF 的行為。是以，建議非必要，莫新增。
通路控制 例如，服務中的權限控制，将所有服務中的權限控制集中在 BFF 層，使下層服務更加純粹和獨立。
應用緩存 項目中時常存在一些需要緩存的臨時資料，此時 BFF 作為業務的彙聚點，距離使用者請求最近，遂将該緩存操作放在 BFF 層。
第三方入口 在業務中需要與第三互動時，将該互動放在 BFF 層，這樣可以隻暴露必要資訊給第三方，進而便于控制第三方的通路。