我为什么要做开源项目 -- illuminant
在做 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 本身就是一个完整的解决方案, 包含了认证, 权限等等, 完全可以直接使用它作为后端.
关键是它有后端管理界面, 创建和维护数据变得非常简单.
