一、前後端分離
- 為什麼選擇前後端分離
- 獨立部署
- 厘清職責
- 技術棧獨立
- 友善系統演進
- 提高效率
- 前後端分離的開發模式
- 按業務的展示邏輯,确認出待展示的内容
- 前後端根據内容,一起細化每個字段名,直至接口确認完畢
- 遇到對接第三方接口時,需要反複進行上一步
- 當各種開發完成時,在測試環境進行內建
- 将完整的業務功能交給QA進行測試
- 前後端分離的API設計
- RESTful API
- 标準的HTTP動詞(又稱HTTP請求方法):GET、PUT、POST、DELETE、PATCH等,每個動詞的用法應該和它的行為一緻
- 狀态碼:20x、40x、50x等常見的狀态碼,都應該正确地使用
- 資源路徑:RESTful API中的URL用于代表資源,應該確定資源能遵循相關的規範,例如,/comments/1傳回第一條評論,/comments/傳回所有的評論
- 參數處理:如果存在大量的參數,那麼我們就需要通過GET帶查詢字元串(Query String)的方式,或者POST帶body的方式來進行傳遞
- API與安全
- Token管理
- 表單校驗
- 權限管理
- 應對API變更
- 統一API接口服務
- API資料模型
- 一緻化處理方式
- 可選的模型适配層
- RESTful API
二、API管理模式:API文檔管理方式
- 傳統方式
- 手寫API文檔
- 口頭約定API
- 離線API文檔
- 線上協作API文檔
- 版本化API文檔
- 代碼即文檔
- 網際網路模式
- HTTP服務即API文檔
- 代碼生成可互動的API文檔,如Swagger
三、前後端并行開發:Mock Server
- 三種類型Mock Server的比較
- 普通Mock Server:HTTP伺服器(如Node.js中的Mock Server架構json-server)
- 支援相關字段的查詢、過濾
- 支援檔案内容的全文搜尋
- 支援正規表達式路由
- DSL形式的Mock Server(如Java語言的Mock Server伺服器Moco)
- 程式設計型Mock Server(如Swagger)
- 普通Mock Server:HTTP伺服器(如Node.js中的Mock Server架構json-server)
- Mock Server的測試:契約測試
- 後端契約測試
- 運作Mock Server
- 發起對Mock Server服務的API請求,擷取相應的傳回資料
- 判斷相應的資料,字段與API中的是否一緻
- 前端契約測試
- 字段名一緻性校驗
- 使用interface接口進行API測試(TypeScript編寫的應用)
- 檢驗邏輯字段
- 後端契約測試
- 前後端并行開發總結
- 前後端約定契約API,并完成對應的Mock Server實作
- 前後端根據各自的邏輯實作對應的業務代碼
- 前後端編寫各種契約測試,并确定API的修改能夠反映到持續內建
- 前後端進行API內建
- 在API修改時,修正對應的API修改
四、服務于前端的後端:BFF
- BFF的API Gateway
- 應對多端應用
- 聚合後端微服務
- 代碼第三方API
- 遺留系統的微服務化改造
- 前後端如何實作BFF
- 傳統後端技術棧下的BFF
- 前端技術棧下的BFF
- 通過Node.js來接收前端發送過來的請求
- 根據請求的類型向對應的背景API服務發起請求
- 獲得傳回結果後進行處理,并向前端傳回對應的結果
- 使用GraphQL作為BFF
- GraphQL優勢
- 按需擷取
- 代碼即文檔
- 易于使用的API調試工具
- 強類型的API檢查
- 易于版本化的API
- GraphQL缺點
- HTTP請求無法被緩存
- 錯誤碼處理不友好
- 學習成本
- 實作複雜
- 基于GraphQL的BFF架構
- GraphQL->API Gateway->後端服務
- GraphQL->REST、RPC等接口的後端服務
- GraphQL->GraphQL接口的後端服務
- GraphQL優勢
推薦閱讀
- 上篇: