在做 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