一、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 中。