在做 illuminant 這個開源專案之前, 一直在尋找一種能夠滿足以下要求的Web介面開發方式:
- 能夠避免撰寫各種繁瑣的業務介面
- 能夠避免撰寫業務介面的測驗代碼
- 業務變化時, 能夠方便的調整資料庫(不用為了兼容之前的介面而各種hack, 弄的資料庫欄位亂七八槽)
- 盡量避免寫各種資料庫查詢SQL
- 有基本的認證和權限
- 方便擴展, 對接其他服務
上面雖然列出了6個需求, 但是核心的訴求總結起來就一個: 自動生成API
這樣, 只要專注于設計資料庫結構, 業務變化時, 改動資料庫就可以生成新的API, 自動生成的API也可以避免大量的API測驗代碼.
自動生成API的框架也有不少, 但是 **靈活性(高) **和 **復雜度(低) **都能滿足要求的卻很難找到.
直到遇到graphql 風格的API, 第一次接觸的時候我有一種在請求中寫SQL的感覺 ??
graphql 雖然主要在前端使用, 但我感覺它對后端開發人員的沖擊更大, 只有經過沒日沒夜開發和修改一堆RESTFul API的開發才能體會到它的好處.
它除了減少了大量介面代碼的開發和測驗, 更重要的是減少了前后端之間的交流溝通(這才是影響開發效率的根源).
前后端開發人員理解的目標一致了, 都是資料庫結構. (之前是后端理解資料庫結構, 前端理解 API 結構)
近幾年, graphql 的相關庫井噴式產生, 各種主流語言的庫非常多, 也證明了這種開發方式的優勢.
于是乎, 我就像用現有的 Web 框架, 對接一個成熟的開源 graphql 服務, 從而能夠大量減少API介面的撰寫.
剛開始用的是 graphile , 后來是 prisma , 最后是現在使用的 hasura
- graphile 產生的比較早, 是強依賴 postgresql 資料庫的, 有很多地方考慮不周, 后來通過各種插件來彌補的.
- prisma 非常好用, 通過定義 yaml 格式的資料結構, 就可以自動生成資料庫和介面, 但是 v2 版本, 變成了一個功能強大的 ORM框架, 不再提供 graphql API出來.
- hasura 是目前 illuminant 專案中使用的 graphql 服務
hasura 本身就是一個完整的解決方案, 包含了認證, 權限等等, 完全可以直接使用它作為后端.
關鍵是它有后端管理界面, 創建和維護資料變得非常簡單.
但是, 之所以不直接使用 hasura , 而是基于 hasura 封裝出 illuminant 這個專案, 是因為:
- 不想重度依賴 hasura, 希望 hasura 成為可以替換的一部分, 而不是全部
- 完全使用 hasura, 就不能使用自己喜歡的語言去擴展
- 業務 API 使用 graphql, 還有其他需求不一定用 graphql
專案檔案: https://www.yuque.com/quyuan-w1et4/awzlgk
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/248843.html
標籤：Go
上一篇：深入理解Go Context