ref: https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-introduction-e4fa965128bf
本篇文章是探討一個前後端互相合作的設計模式，Backend For Frontend 簡稱為 BFF。
文章開頭，作者舉了一個常見的應用情境，假設團隊需要基於微服務的概念去設計一套電商系統，背後服務包括了購物車，訂單，產品，顧客...等不同類型的資料。
但是很容易後端所回傳的資料格式並不能完全直接符合前端的需求，這意味前端必須要維護一套邏輯來轉換資料格式來符合其需求。
基於這種情況，作者希望將前端這些轉換格式的邏輯給抽出來並且移動一個中間層來進行處理，而這個中間層也就是所謂的 BFF。
當前端需要請求一些資料時，前端會對 BFF 去發送 API，而此時 BFF 會執行下列行為
1. 呼叫對應的 backend 服務來獲得需要的資料
2. 根據前端的需求將獲得的資料進行格式轉換
3. 將轉換後的格式回傳前端
這種架構下，能夠讓前端的程式邏輯更為簡單與乾淨
接者作者針對 BFF 的架構又探討了幾個問題，分別
The role of a BFF
1. BFF 單純就是一個前後端中間的轉換介面
2. 前端 Team 要負責維護這個 BFF 的應用程式
3. 每個 BFF 就是針對一個前端，一個 UI 去設定，同時盡可能地讓前端程式碼保持單純與專注
Will this increase latency?
由於 BFF 就是一個前後端中間的轉換層，這是否意味所有請求都會需要花費更長的時間來處理，
答案是沒錯，每個請求只要經過愈多的節點整個花費時間會增加是不可避免的。
不過作者認為這個帶來的影響微乎其微，特別是當瀏覽器介面本身需要需要跟眾多沒有針對前端最佳化的服務取得資料時，BFF 帶來的影響基本上可以忽略。
此外，作者認為透過 BFF 的架構可以讓前端更容易得基於批次的概念來一口氣呼叫眾多後端服務同時於一個 reply 中取得全部所需的資料，甚至直接得更為方便呈現的資料格式。
作者提到這個特色針對 2G/3G 這種本身需要花上數秒鐘才可以建立連線的網路情況來說特別有效，減少向後建立連線的數量，反而能夠讓前端更有效率地去呈現畫面。
When to use a BFF for your applications
如同其他眾多的設計模式一樣， 使用 BFF 也是要依據團隊的使用情境與架構來判別。 假設團隊的應用程式是一個 monolithic 的架構，則 BFF 基本上幫不上什麼忙，帶來的好處微乎其微。
不過如果是基於微服務的架構的話，則 BFF 就有機會可以幫上忙。
文章中還有針對 BFF 的架構圖是以及其他相關好處，譬如
1. Separation of concerns
2. Easier to maintain and modify APIs
3. Better error handling in the frontend
4. Multiple device types can call the backend in parallel
5. Better security
6. Shared team ownership of components
有興趣的可以參考看看原文
api回傳格式 在 Web API 回傳資料的方式 - Ron 2.0 的推薦與評價
這篇是要稍微記一下Web API 回傳資料的幾種方式與格式, 會想要記這一篇是因為以前碰過的Web API 專案都有統一的回傳(response) 格式, 但是最近碰到 ... ... <看更多>
相關內容