BFF字面意思是服務於前端的后端，我的理解就是數據聚合層。我們組在維護一個后台管理系統，會頻繁的與數據庫交互。
過去為了增刪改查會寫大量的對應接口，並且還需要在Model、Service、Router三層寫不同的代碼邏輯，吃力不討好。
為了節約開發時間，構思通用接口，並付諸於實際項目中。雖然簡化了Router和Service部分，但其實就是將該部分的代碼遷移到了前端頁面中。
這里有一點小隱患，因為目前我們組的成員是全棧維護，所以知道數據庫ORM的語法規則，若前后端分離，那就不可取了，並且工作量其實是從后端轉移到了前端。
雖然時間是節約了一些，但是后端的代碼卻暴露在了前端，維護性方面下降了不少，於是想到了BFF。
首先查看了許多已經在運行的成功案例，有些是基於GraphQL重新封裝的系統，有些是定制化的系統。經過三天的仔細權衡對比后，決定自己定制化。
主要考慮了兩方面，一方面是改造成本，如果基於GraphQL的一些封裝庫（例如Type-GraphQL、apollo、Prisma等）來設計系統的話，那勢必需要了解這些的庫的方方面面，並且還需要將其集成到已經的結構中。
另一方面是使用成本，系統完成后是給人用的，不能太復雜，為了避免讓使用人員來適應這套系統，最方便的就是將之前的開發流程修改成配置化。
BFF的實現邏輯由后端定義，並且⽆需重構，也不必后端配合改造與聯調。
這套系統完成后，會真真切切地影響之前的開發流程，例如不必單獨寫接口文檔，並且可以隨時在系統中調試，而不必借助postman調試。
一、前端界面
1）配置
當前80%的Node接口代碼復雜度都並不⾼，基本都是機械化重復的，這些接口可分為三部分：參數處理（1）、服務調用（2）和響應聚合（3），類似於下圖。
那么前端界面就可以圍繞這三部分展開，如下圖所示，其中處理器就是服務調用，只是會基於通用接口服務和指定的Model的封裝函數。
權限ID就是一段字符串，會在權限系統做接口校驗，具體會在后文講解。模塊其實就是之前Router目錄中的各個文件，現在將它們作為選項存在。
參數是可以動態配置的，處理器也是一樣，並且在選中方法后會顯示方法名和方法參數，而在選好Model文件后，會出現查看按鈕。
點擊查看按鈕就能看到Model文件中映射的屬性，以及數據庫表的字段了，在之前的開發中經常需要查找這些屬性和字段，甚是繁瑣。
邏輯結構就是接口的主體，除了參數部分的代碼不需要寫之外，其余代碼都在這里完成，是整個接口最為核心的部分。
這部分的處理我其實考慮了很久，在簡便和自定義之間找到了一個平衡點，最終才實現了上述效果。
之前聲明的參數和處理器都可以在這個編輯器中引用，這個代碼編輯器采用的是monaco-editor，微軟出品的VS Code瀏覽器版本，該有的功能都有。
但是我只集成了代碼高亮的功能，自動索引的功能沒有成功集成進來，順便說下，官方的API文檔非常不友好。
2）調試
在配置化界面的最下方，就是調試部分，當接口創建完成后，就能馬上調試。
點擊API文本框中的搜索icon，就能看到最終的源碼了，能幫助自己迅速定位問題。
3）列表
在列表界面中，包含新建的入口，以及查看和編輯。當跳轉到創建頁面后，點擊瀏覽器的返回鍵，列表頁面能恢復成之前的樣子。
列表頁面的狀態不會受跳轉的影響。點擊查看會出現配置信息、源碼和調試界面，這些配置信息就是接口文檔，並且還能隨時調試。
二、后端服務
這次我將API接口的數據都存儲在MongoDB中，主要考慮的是數據中會包含大量的數組和JSON對象，若存在MySQL中，就需要在存入和取出時做序列化和反序列化。
1）vm
后端在接收到界面中的參數后，就會將相關參數解析成對應代碼，再拼接成一整段的字符串代碼。執行這段代碼使用的是Node內置的vm模塊。
const sandbox = { ctx, services, console, redis, mainFunc: function () {} //主函數 }; vm.createContext(sandbox); // 在執行上下文運行 vm.runInContext(code, sandbox); await sandbox.mainFunc();
在sandbox變量中，特地聲明了一個mainFunc屬性，因為執行的代碼中會使用await語法，那么就需要將代碼包在由async聲明的函數中。
2）接口調用
Node服務基於KOA框架，路由基於koa-router庫，為了盡量與之前的調用方式保持一致，就重新聲明了一個可配置的路由。
router.all("/bff/:path1/:path2", async (ctx) => {
const { path1, path2 } = ctx.params;
const bff = await services.common.getOneBFF({ api: path1 + "/" + path2 });
if (!bff) {
return;
}
//權限判斷
if (bff.authority) {
const pass = await checkAuth(ctx, bff.authority);
if (!pass) return;
}
//運行代碼
await runCode(bff.rawCode, ctx);
});
在這個方法中，配置了兩個路徑參數path1和path2，所有通過這套BFF系統創建的接口，在前端調用時，都需要添加 /bff/ 前綴。
而權限判斷都會交由 checkAuth() 函數處理，之前這個函數是一個中間件，那么將其關鍵部分抽象出來后，也能達到權限驗證的效果，與普通接口無異。