graphQL - 尝试

1. 介绍 graphQL 前, 先简单说下最常用的 restful 接口规范

  • 1.1 REST(Representational State Transfer)表现层状态转化
  • 1.2 特点:资源、统一接口、URI、无状态
  • 1.2.1 每个 URI 都对应一个特定的资源
    315478c6d7f84ce4b244c05f01681a80_blob.png
    例如: url 上的 advertise 表示获取广告
  • 1.2.2 统一接口 RESTful 架构风格规定,数据的元操作 即 CRUD 分别对应 HTTP 方法
    GET - 查
    POST - 增
    PUT - 改
    DELETE - 删
    1. RESTful 的缺点
    • 2.1 因其 URI 的特点,导致数据库里有多少张表,api 接口也会对应的有多少个
    • 2.2 RESTful 面向的是微服务化,导致缺少聚合数据,可能需要后端额外开接口来做
    • 2.3 随着版本迭代,接口吐出的数据会越来越庞大,增加数据传输时间
    • 2.4 前端入参 与 后端返回数据模型不对等,导致前端不清楚后端到底会返回什么
  1. graphQL facebook2015 年提出,已被大量用于阿里巴巴,github,facebook,leetcode 等公司
    这是我们在数据库里的用户表
    ffcd8edc2fb5485aa62f6e47bd986650_blob.png
    • 3.1 优点,天生自带聚合操作
    • 3.2 客户端 / 前端能准确获得它需要的数据,而且没有任何冗余
    • 3.3 前端发送请求时,已经知道返回的数据结构,字段等
      这是我们聚合了查询 userList,userItem
      698e5cf6cbba476e8b4b90181c822d4a_blob.png
      我们,可以看到前端需要什么字段,请求的数据也会传过来,返回的时候只会返回前端需要的数据
    • 3.4 类型系统 - 弥补了 js 的类型缺陷
  2. 服务端代码实现
    以 node.js 为例 (koa2 框架)
    项目结构
    a4a6cc370e2f49bf8fbef8e01e228bc1_blob.png

    在 graphQL 中,查询对应的 query, 增改删对应的 mutation

    • 3.1 查
      graphQL 允许对每一个字段进行 resolve
      示例为处理 userList
      15742756181446c9b46f0b85aac45de2_blob.png

    在来看看 GraqhQLlist 到底是什么
    38c6381988864c71bb513d8e5863fc38_blob.png

    可以看到,每一个 userType 下的每个字段,我们都定义了类型 - 实际上是对 model 层的一个映射
    9a452c0709c641b1a358a80ea3a4aba2_blob.png

    查单个用户
    多了一个 args 字段,用来描述 user_id
    738e69c0f6cd4685a3f0d0d709122c98_blob.png

    • 3.2 增改删
      以增加用户为例
      e67fe61541ab4606a628e77df20b54c3_blob.png

    请求
    2fd46fd268574668949334b4a4ee6f25_blob.png

    -3.3 异常处理
    graphQL 自带了异常处理,如果前端需要的字段后端没有,或者入参缺少 / 类型不对都会报错
    如:e40d30b7d9994ba886df4c8c5f6b06da_blob.png
    f06b10fc4f7e45fa9809fb45cffa7f32_blob.png

  • 4 前端代码示例
    以 Angular6.x,typescript 为例
    0e394f8dca014bd8bfe7ba8ff6933d8a_blob.png
    因为查用户列表,查用户详情有公共的 返回参数,所以我们这里使用了 graphQL 里的 frament