我爲何要作開源項目 -- illuminant

在作 illuminant 這個開源項目以前, 一直在尋找一種可以知足如下要求的Web接口開發方式:

1. 可以避免編寫各類繁瑣的業務接口
2. 可以避免編寫業務接口的測試代碼
3. 業務變化時, 可以方便的調整數據庫(不用爲了兼容以前的接口而各類hack, 弄的數據庫字段亂七八槽)
4. 儘可能避免寫各類數據庫查詢SQL
5. 有基本的認證和權限
6. 方便擴展, 對接其餘服務

上面雖然列出了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 這個項目, 是由於:

1. 不想重度依賴 hasura, 但願 hasura 成爲能夠替換的一部分, 而不是所有
2. 徹底使用 hasura, 就不能使用本身喜歡的語言去擴展
3. 業務 API 使用 graphql, 還有其餘需求不必定用 graphql

項目文檔: https://www.yuque.com/quyuan-w1et4/awzlgk