BFF字面意思是服務于前端的后端，我的理解就是數據聚合層。我們組在維護一個后臺管理系統，會頻繁的與數據庫交互。   過去為了增刪改查會寫大量的對應接口，并且還需要在Model、Service、Router三層寫不同的代碼邏輯，吃力不討好。   為了節約開發時間，構思[通用接口](https://www.cnblogs.com/strick/p/15042209.html)，并付諸于實際項目中。雖然簡化了Router和Service部分，但其實就是將該部分的代碼遷移到了前端頁面中。   這里有一點小隱患，因為目前我們組的成員是全棧維護，所以知道數據庫ORM的語法規則，若前后端分離，那就不可取了，并且工作量其實是從后端轉移到了前端。   雖然時間是節約了一些，但是后端的代碼卻暴露在了前端，維護性方面下降了不少，于是想到了BFF。   首先查看了許多已經在運行的成功案例，有些是基于GraphQL重新封裝的系統，有些是定制化的系統。經過三天的仔細權衡對比后，決定自己定制化。   主要考慮了兩方面，一方面是改造成本，如果基于GraphQL的一些封裝庫（例如[Type-GraphQL](https://typegraphql.com/)、[apollo](https://www.apollographql.com/)、[Prisma](https://www.prisma.io/)等）來設計系統的話，那勢必需要了解這些的庫的方方面面，并且還需要將其集成到已經的結構中。   另一方面是使用成本，系統完成后是給人用的，不能太復雜，為了避免讓使用人員來適應這套系統，最方便的就是將之前的開發流程修改成配置化。   BFF的實現邏輯由后端定義，并且?需重構，也不必后端配合改造與聯調。   這套系統完成后，會真真切切地影響之前的開發流程，例如不必單獨寫接口文檔，并且可以隨時在系統中調試，而不必借助postman調試。 ## 一、前端界面 **1）配置**   當前80%的Node接口代碼復雜度都并不?，基本都是機械化重復的，這些接口可分為三部分：參數處理（1）、服務調用（2）和響應聚合（3），類似于下圖。 :-:    那么前端界面就可以圍繞這三部分展開，如下圖所示，其中處理器就是服務調用，只是會基于通用接口服務和指定的Model的封裝函數。 :-:    權限ID就是一段字符串，會在權限系統做接口校驗，具體會在后文講解。模塊其實就是之前Router目錄中的各個文件，現在將它們作為選項存在。   參數是可以動態配置的，處理器也是一樣，并且在選中方法后會顯示方法名和方法參數，而在選好Model文件后，會出現查看按鈕。 :-:    點擊查看按鈕就能看到Model文件中映射的屬性，以及數據庫表的字段了，在之前的開發中經常需要查找這些屬性和字段，甚是繁瑣。   邏輯結構就是接口的主體，除了參數部分的代碼不需要寫之外，其余代碼都在這里完成，是整個接口最為核心的部分。 :-:    這部分的處理我其實考慮了很久，在簡便和自定義之間找到了一個平衡點，最終才實現了上述效果。   之前聲明的參數和處理器都可以在這個編輯器中引用，這個代碼編輯器采用的是[monaco-editor](https://microsoft.github.io/monaco-editor/)，微軟出品的VS Code瀏覽器版本，該有的功能都有。   但是我只集成了代碼高亮的功能，自動索引的功能沒有成功集成進來，順便說下，官方的API文檔非常不友好。 **2）調試**   在配置化界面的最下方，就是調試部分，當接口創建完成后，就能馬上調試。 :-:    點擊API文本框中的搜索icon，就能看到最終的源碼了，能幫助自己迅速定位問題。 :-:  **3）列表**   在列表界面中，包含新建的入口，以及查看和編輯。當跳轉到創建頁面后，點擊瀏覽器的返回鍵，列表頁面能恢復成之前的樣子。 :-:    列表頁面的狀態不會受跳轉的影響。點擊查看會出現配置信息、源碼和調試界面，這些配置信息就是接口文檔，并且還能隨時調試。 :-:  ## 二、后端服務   這次我將API接口的數據都存儲在MongoDB中，主要考慮的是數據中會包含大量的數組和JSON對象，若存在MySQL中，就需要在存入和取出時做序列化和反序列化。 **1）vm**   后端在接收到界面中的參數后，就會將相關參數解析成對應代碼，再拼接成一整段的字符串代碼。執行這段代碼使用的是Node內置的[vm模塊](http://nodejs.cn/api/vm.html)。 ~~~ 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() 函數處理，之前這個函數是一個中間件，那么將其關鍵部分抽象出來后，也能達到權限驗證的效果，與普通接口無異。 ***** > 原文出處： [博客園-Node.js躬行記](https://www.cnblogs.com/strick/category/1688575.html) [知乎專欄-Node.js躬行記](https://zhuanlan.zhihu.com/pwnode) 已建立一個微信前端交流群，如要進群，請先加微信號freedom20180706或掃描下面的二維碼，請求中需注明“看云加群”，在通過請求后就會把你拉進來。還搜集整理了一套[面試資料](https://github.com/pwstrick/daily)，歡迎閱讀。  推薦一款前端監控腳本：[shin-monitor](https://github.com/pwstrick/shin-monitor)，不僅能監控前端的錯誤、通信、打印等行為，還能計算各類性能參數，包括 FMP、LCP、FP 等。