掌門教育前端技術分享會第一期已于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 集成系統，千尋位置網自己也實作了一套，這個就比較因人而異了
更多精彩內容，歡迎關注
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/253071.html
標籤：其他