【大咖分享】BFF在千尋位置網前端的落地和演進

掌門教育前端技術分享會第一期已於1.23號落幕，如下爲大咖講師們現場演講的整理稿，感謝你們的支持：

講師介紹

唐兵，前端技術專家，來自千尋位置網業務中臺前端團隊 負責團隊電商相關業務開發，團隊BFF層技術負責人 團隊平常工做內容，主要對公司門戶、電商、營銷、分銷等業務提供前端支持，業務覆蓋 PC、H五、App、小程序、NodeJS 等各類技術場景。

如下爲唐兵同窗的部分精彩演講內容：

BFF的歷史演化進程

前端BFF層，咱們大概經歷了四個階段：

1. serverAPI：後端直接將接口暴露給前端開發，進行業務調用，也是咱們前端開發最常接觸到的模式。
2. internalRest：後端同窗在底層service數據接口的基礎上，進行業務頁面邏輯聚合處理，再透傳到前端進行頁面數據渲染。
3. Apoll-Graphql：業務接口聚合結構化、模塊化，目前這塊是由咱們千尋位置網前端開發同窗牽頭；這裏的背景是，目前公司後端服務基本都是採用微服務化開發，接口數據都是原子化交付，
4. Apoll-Federation：在Graphql基礎上，作支撐服務的拆分，以提供更好的開發體驗

目前，千尋位置網前端處於第三向第四階段過渡

InternalRest

對應後端開發同窗來講，強耦合頁面展現邏輯的開發方式來開發API，開發體驗不好、有干擾，internalRest能夠幫助開發同窗作開發分層，把拼接數據這一層的邏輯從數據的核心模塊裏面剝離出去，後端的數據模型能夠跟具體頁面邏輯無關；

這種方式在先後端分離的開始階段，確實會極大的加速業務開發，但隨着業務的不斷髮展，不少非業務模型的必要字段難以維護；這就是典型的【數據的生產者和數據的消費者之間的工做邊界不清晰】

Apoll-Graphql

爲何選擇graphql，

1. graphql容許前端開發同窗能夠自定義數據字段，它提供配置式的方式來定義、裁剪數據結構，前端同窗無需寫冗餘代碼
2. graphql能夠很是方便的幫助咱們，實現業務頁面的數據聚合，好比咱們一個商城系統，有商場列表、購物車、公告信息等等，這裏咱們能夠經過一個graphql的定義接口，就拿到全部數據，減小接口請求數量
3. 結合graphql強制要求描述數據類型，咱們能夠很是清晰、直觀的理解每個數據的具體含義

NestJs-Graphql

爲何推薦使用NestJs：

咱們在實際的項目開發中發現，在開發server層時，強類型語言的開發方式對數據更友好，NestJs相對於Koa來講，對數據類型支持更好，另外NestJs提供了不少通用的模塊功能，好比使用Guard作用戶校驗，filter作數據異常的處理等等

Apoll-Federation

目前千尋位置網，不少的業務場景下面，前端BFF層程序並非直接對外暴露的，而是經過web-gw（網關）來作分發，經過網關層再來作接口聚合，這樣萬一輩子產某一個服務發生錯誤異常，仍然能夠保證咱們其它的服務不會受影響

Gateway是經過數據schema定義來聚合具體業務數據，而且它能夠支持跨項目式schema格式獲取，能夠極大的方便咱們跨項目開發

Gateway除開項目代碼內定義schema結構外，還提供了遠程push-pull方式拉取schema結構，不過Apollo官方未提供獨立部署的解決方案，須要咱們本身開發一套 Schema 集成系統，千尋位置網本身也實現了一套，這個就比較因人而異了

更多精彩內容，歡迎關注