面向前端的後端模式(BFF)

banq發表於2018-10-05
前端後端模式
Backend For Frontend API設計是一種為前端設計的專門後端API，主要是為解決常見的前後端API衝突。

讓我們看一下常見API設計前端/後端衝突的三個示例，然後尋找解決它們的方法。

示例衝突＃1：響應的格式化
前端開發人員通常要求後端響應能滿足特定結構以匹配螢幕設計。雖然在後端API中解決響應格式化要求似乎很簡單，但可能會出現以下幾種情況：

1.前端虛擬化需要以特定方式聚合的資料，從而減少構建螢幕所需的編碼工作量。

2. 團隊正在將現有螢幕遷移到以API為中心的新架構，並且不希望將10到100個螢幕進行重做才能匹配新的內容格式

團隊之間為此爭論響應格式工作到底應該是誰來實現？後端開發人員希望實現普通的JSON，JSON API，HAL，Siren，Hydra或其他格式，以實現穩定的和互操作性。而前端開發人員通常需要特定格式，才能更容易渲染這些資料。我被要求成為這些衝突中的決鬥者。

超媒體驅動的有效載荷特別有趣，因為後端API可以透過嵌入相關資源摘要來設計用於移動消費。這可能導致n + 1查詢等問題，因為客戶端被迫為相關資源對超媒體連結進行遍歷導航。讓我們接下來研究這個衝突。

示例衝突＃2：由於n + 1 API呼叫導致的效能問題
你可能以前從n + 1個查詢中遇到過資料庫效能問題。當應用程式執行初始資料庫查詢，然後對第一個查詢的每個結果執行新的資料庫查詢時，會發生n + 1查詢問題。對於產生100個結果的查詢，應用程式進行101次資料庫呼叫。這不是構建Web應用程式最高效的方法。

雖然資料庫n + 1查詢可能會影響我們的Web應用程式效能幾百毫秒左右，但由於網路延遲的增加，對API的影響要大得多。此外，API使用者通常需要編寫大量工作來編寫客戶端程式碼以獲取初始API響應，然後執行數十到數百個後續API呼叫以獲取其他資料並構建必要的資料結構以驅動單個Web或手機螢幕。

n + 1 API呼叫的關鍵指標是一個問題：

1.目標裝置具有有限的網路頻寬，並且需要由後端API提供其他資料

2.開發人員設計了響應內容，但沒有相關資源的摘要詳細資訊，迫使API客戶端使用者自己解決問題。

與上面的示例＃1不同，此問題的影響不僅限於前端開發人員。相反，效能問題可能會暴露給客戶，從而導致糟糕的使用者體驗和客戶流失。

示例衝突＃3：以資料庫為中心的API設計
當團隊說他們使用REST作為他們的API時，它幾乎可以說是任何東西。從RPC風格的API到構建超媒體REST以及介於兩者之間的所有API - API設計可以有各種不同的方法。

一種流行的方法是使用API​​包裝資料庫。我不推薦這種方法，因為基於Web的資源通常需要代表更加系統的系統視角，幷包含客戶端的工作流程。

直接的CRUD-over-database方法確實帶來了自己的衝突：

1. 緊密耦合到資料庫模式，導致在重新命名或刪除列時更改API欄位名稱，

2. 缺少更高階別的工作流端點，強制執行多個API呼叫以實現目標（類似於上面的n + 1問題）

根據我的經驗，這似乎是最常見的，因為API通常是從現有資料庫自下而上設計的。然後，前端團隊必須努力將以解決方案為中心的使用者介面對映到以資料庫為中心的API設計。但是，後端開發人員往往不願意或無法進行適當的更改來最佳化完成所需的API呼叫。

透過分層API設計解決衝突

這場衝突的根源：

1. 前端團隊希望透過要求響應內容符合介面設計並在適當的時候限制API呼叫，從而來減輕編碼負擔。

2. 後端開發人員希望最佳化端點以實現重用和快速開發


要解決這個衝突，我們需要找到一種方法來支援雙方。這樣做的常用方法是使用分層API設計。在微服務世界內，這通常被稱為前端後端（BFF）模式。

BFF模式允許後端API保持原樣，前端開發人員構建和使用新API以滿足UI的需求。使用BFF模式有兩種主要方法：

1.以應用為中心的方法：

由終端使用者的用例驅動，通常與使用者的工作流程相關。

傳統的後端API則被視為較小的可組合端點，透過將這些較小的可組合端點組合到新API中來實現終端使用者的用例需求。

這類似於傳統的SOA或微服務


2.以裝置為中心的方法：

由裝置功能驅動（例如移動應用，網路），鼓勵跨裝置API重複程式碼，根據需要調整響應內容甚至行為，減少在不可靠網路如行動網路之間的往返次數。


這兩種方法都支援將業務流程推向更靠近後端API所在的伺服器層，並且有降低網路延遲的想法。這會將客戶端網路流量減少到僅對BFF API進行一次或兩次API呼叫，這對移動應用程式而言非常重要。

請謹慎應用前端後端（BFF）模式
Backend For Frontend API設計模式是團隊解決衝突並確保API解決實際問題的有用工具。一個主要缺點是，這會建立另一個需要在應用程式生命週期內維護的API。對於大型組織而言，這可能不是問題; 但是，較小的團隊可能很難跟上後端API和一個或多個前端API的變化。

另一個危險是這些分層API不像“旗艦核心”平臺API那樣被認真對待。安全性，文件，測試和設計方面的失誤可能會蔓延到這些API中，從而使產品暴露出各種問題。最壞的情況是，個人身份資訊（PII）可能在未經適當授權的情況下發布，或者行業/政府法規可能會受到損害。

在構建裝置或以應用程式為中心的API以解決這些衝突時，請不要圖省事，將所有的細節都要納入API產品本身設計。

原文

相關文章