我为何要作开源项目 -- 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