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

 

 posted on 2021-08-09 08:02  咖啡机(K.F.J)  阅读(280)  评论(5编辑  收藏  举报