掌門教育前端技術分享會第一期已於1.23號落幕，以下爲大咖講師們現場演講的整理稿，感謝大家的支持：
講師介紹
唐兵，前端技術專家，來自千尋位置網業務中臺前端團隊
負責團隊電商相關業務開發，團隊BFF層技術負責人
團隊日常工作內容，主要對公司門戶、電商、營銷、分銷等業務提供前端支持，業務覆蓋 PC、H5、App、小程序、NodeJS 等各種技術場景。
以下爲唐兵同學的部分精彩演講內容：
BFF的歷史演化進程
前端BFF層，我們大概經歷了四個階段：
- serverAPI：後端直接將接口暴露給前端開發，進行業務調用，也是我們前端開發最常接觸到的模式。
- internalRest：後端同學在底層service數據接口的基礎上，進行業務頁面邏輯聚合處理，再透傳到前端進行頁面數據渲染。
- Apoll-Graphql：業務接口聚合結構化、模塊化，目前這塊是由我們千尋位置網前端開發同學牽頭；這裏的背景是，目前公司後端服務基本都是採用微服務化開發，接口數據都是原子化交付，
- Apoll-Federation：在Graphql基礎上，做支撐服務的拆分，以提供更好的開發體驗
目前，千尋位置網前端處於第三向第四階段過渡
InternalRest
對應後端開發同學來說，強耦合頁面展示邏輯的開發方式來開發API，開發體驗很差、有干擾，internalRest可以幫助開發同學做開發分層，把拼接數據這一層的邏輯從數據的核心模塊裏面剝離出去，後端的數據模型可以跟具體頁面邏輯無關；
這種方式在前後端分離的開始階段，確實會極大的加速業務開發，但隨着業務的不斷髮展，很多非業務模型的必要字段難以維護；這就是典型的【數據的生產者和數據的消費者之間的工作邊界不清晰】
Apoll-Graphql
爲什麼選擇graphql，
- graphql允許前端開發同學可以自定義數據字段，它提供配置式的方式來定義、裁剪數據結構，前端同學無需寫冗餘代碼
- graphql可以非常方便的幫助我們，實現業務頁面的數據聚合，比如我們一個商城系統，有商場列表、購物車、公告信息等等，這裏我們可以通過一個graphql的定義接口，就拿到所有數據，減少接口請求數量
- 結合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 集成系統，千尋位置網自己也實現了一套，這個就比較因人而異了
