一、GraphQL
最近服务端的同事分享了GraphQL，他分享的目的就是要把我们与他们的数据库隔离，这么做我们也求之不得。
我们组目前维护着一个后台管理系统，会直接读取数据库中的表，如果能隔离的话，就不需要写Model文件了。
后面再进一步了解后，明白了服务端推这个GraphQL的用意，其实就是让我们自己去维护GraphQL服务，包括客户端也去自己维护。
那这和我直接读取数据库做路由，区别不是很大了，无法解决当前我们的痛点，而且我在前端页面中还需要制定数据结构，比之前还多了一步。
况且如果需要缓存的话，还不能直接调用GraphQL的接口。如果我们人员充沛的话，这么分一点问题都没有，但是现在人员非常紧张。
我们还要花大精力做数据整合和处理，而前端常规的工作诸如性能优化、页面交互、组件化、工程化等都没时间深入研究。基于此，还得另辟蹊径。
二、通用接口
由于后台管理系统大部分的操作都是增删改查（数据库基于MySQL，ORM基于Sequelize），所以可以抽象出一套这类的通用接口，从而就能避免在 Router 和 Service 两层中新增不必要的文件。
- api/get：读取一条数据（单表查询）
- api/gets：读取多条数据（单表查询）
- api/head：读取聚合数据，例如count()、sum()、max()和min()
- api/post：提交数据，用于增加记录api/put：更新数据
这套接口的研发受到了 APIJSON 这套开源项目的启发。
数据库表都是单表查询，不支持联表，若要联表则单独创建接口。查询条件的语法直接参照 Sequelize，没有做单独的语法编译。
由于接口的参数是一个JSON格式的对象，因此全部采用 post 的请求方式（Content-Type: application/json）。
以 api/get 为例，基于KOA框架，在 Service 层的方法是：
/** * 数据库查询一条记录 */ async getOne(tableName, where={}) { return this.models[tableName].findOne({ where, raw: true }); }
在 Router 层的方法是：
/** * 读取一条记录 * { * TableName : { 查询条件 } * } * TableName是Model文件的名称，并非数据库表名 */ router.post('/get', async (ctx) => { const { body } = ctx.request; const tableName = Object.keys(body)[0]; //表名 const where = body[tableName]; //查询条件 // 将表名和查询条件传递给数据库方法 const data = await services.common.getOne(tableName, where); ctx.body = { code: 0, data }; });
其中 TableName 是服务端中Model的文件名（并非数据库中的表名），对象中的字段都是SQL的查询条件。
粗略估算一下，如果将管理系统的接口替换成通用接口，那么可节省至少450个接口，占总接口的40%左右，并且 Service 中的方法也会大大减少。
已将通用接口的前端代码整合到 shin-admin 中，后端代码整合到 shin-server 中。
