写在最前

我不是写一个 GraphQL 的使用指南, 是在写自己对 GraphQL 的一些使用感受. 我自己是非常喜欢它, 愿意给他打10分, 虽然还有些小瑕疵. 如果你用过 GraphQL 了, 可以看看我们是不是有同感.

另外多提两句. 1 GraphQL 本身是一个协议, 每种语言都有自己的框架实现, 我自己只用过 Java 的. 2 他是一个执行引擎, 不是 HTTP 框架, 你可以在任何地方使用他们, 当然现在最常见的是提供 HTTP 接口.

当前开发模式(未使用 GraphQL 前)

先说 API 协议设计上面.

请求(Request): Client 给需要的一些参数. 拿取文章列表这个接口举例: 请求中给分页大小 当前是第几页 排序方法(热度/发布时间/打分等).

响应(Response): 就是按需要给 Client 返回他需要的字段.

然后简单说一下代码实现上面.

从数据库,或者是别的服务接口取回需要的数据, 然后按一定的逻辑做一些过滤, 做一些字段的组装, 返回给调用者.

痛点

  1. 难以做到按需提供 API. 这是 GraphQL 着重宣传的点, 但我的觉得后面两点才是 GraphQL 更爽的地方.

    想像一样, 我们给客户 A 提供了一个文章列表的 API. 后面客户 B 说我们还需要文章作者的昵称. 我们就要在 API Response 里面再添加一个字段, 但这个字段 A 并不需要. 后面客户 C 又说我们需要另外一个字段, 字段可能会越加越多, 而其他人可能并不需要.

    取有些字段可能还会比较费时, 那么给 C 加的字段导致 A 调用时长增加了. 这时候, 我们可能会在 Request 里面增加一个参数, 可以默认不返回某字段, 只有 C 调用的时候才返回这个字段.

    又比如说, 用户 A 需要对每篇文章返回10条评论,C 需要20条.我们又需要一个参数,这些参数基本上都是最外层的,没有规范的命名标准.

    总的来说, 没有一套规范, 这点和 GraphQL 有鲜明的对比.可能每个点都可以用自己的方法解决掉,但 GraphQL 是降维打击

  2. Do Dto Ao Vo 等各层对象转来转去. 增加一个字段, 可能会在每个转换的地方都要修改代码, 非常繁琐.

  3. 飞线代码多, 逻辑分散在各个地方, 特别是多人开发, 项目多次转交后.

    就我自己的实际经验, 来举个例子, 一个新接手的项目. 文章作者下面有标签字段, 包含标签类型和标签名字. 新需求想把一个接口A 里面的作者标签做些过滤, 某种类型的标签就不要返回了.

    AuthorService 生成 Author 以及标签的函数, 被多个其他函数引用, 这些函数又被引用, 最后被多个接口使用. 那对我来说, 完成需求的最简单的方法, 就是在接口 A 最后返回的时候, 把标签过滤一下. 我把这段代码叫做飞线代码. 时间长了, 这种情况多了, 飞线越来越多, 字段的值可能会在多个地方, 在不同的逻辑下被修改. 给 Debug 和代码可读性带来痛苦.

GraphQL 优势

减少 dto - ao - vo 转换

各种 O(Object) 的定义: 阿里巴巴Java开发手册中的DO、DTO、BO、AO、VO、POJO定义

这些各种 O 的转换, 本意大概是想让代码更清楚, 减少耦合. 但实际上, 给我的体验非常糟糕, 添加一个字段需要在多个 O 之间转来转去. 我接过一个项目, 只是数据库里面多一个字段返回给前端, 需要修改大概10处代码, 就只是在 OOO 之间Get/Set

GraphQL 里面(特指 Java 框架,其他语言的没有用过), 因为 data mapping 和 DataFetcher 的存在, 实际操作下来, 并不需要这些 OOO 之间的转换, 而且逻辑反而更清楚.

代码复用

虽然这里是写了”代码复用”, 但更像一种配置的复用. 我觉得比代码复用更简单, 更清楚, 写起来更简单, 别人看起来也一目了然.

这个是 GraphqL 的框架本身的优势 (这里也特指 Java 的). 因为他的逻辑在字段和 DataFetcher 的绑定这里, 而不在具体的业务代码里面.

举下例子吧.

文章里面有返回作者字段(里面有头像,昵称等字段). 评论(Comment)现在也要加作者字段. 在之前的开发模式下呢, 就是找到评论这块代码, 通过评论里面的 authorId 去调用 AuthorService 代码, 返回到 Comment 对象里. 这里我这里只用了一句话来说明需要做什么, 但实际上, article->comment->author 一层层找下去, 并不是很愉快的事, 这里还只三层而已. 另外还有dto - ao - vo 转换让我非常头疼.

GraphQL (Java框架) 里面, 只要把 Comment 的 Author 字段绑定到 AuthorFetcher 就好了, 应该就一行代码.

逻辑清晰

这个是针对前面提到的飞线代码. 因为 GraphQL 天然的一个字段对应一个 DataFetcher, 所以逻辑再怎么飞也飞不多远. 在 GraphQL 里面做一些逻辑的修改是很愉快的事.

更自然的并行

也许吧, 我只是列在这里了, 其实对这一点, 我自己的感受并不深刻. 可能是我们的 QPS 太低, 对响应时间也不太苛刻, 不用并行也无所谓, 感受不到.

规范化的批量处理

比如说有好多地方需要使用 imageId 去取 image 的具体信息, 你会把这些地方合并起来批量去取吗? 你可能会很纠结, 因为代码写起来会麻烦一些, 而且充满了回调这样的东西. GraphQL 里面的 DataLoader (java 特有? 不确定) 为你提供了一个规范的批量处理的方式, 而且使用非常自然.

但他未必能把所有 imameId 收集到一起再批量去取. 请阅读和实践一下 Dispatch 的概念, 还有 dataLoader 那一篇官方文档. 我觉得这是 GraphQL 的一个缺陷, 但已经够好了, 不是吗?

一些实践经验

设计好schema

很想把这句放到文章最前面, 怎么强调都不过分. 要按照天然的数据结构和层次来设计 Schema, 天然的结构是指按 DB 里面的表结构, 以及其他接口返回的数据结构等等. 我觉得这是自然而然的事情, 但还是要说一下, 以免有人会有老一套思维定势, 觉得这样不合理.

如果你或者前端同学觉得这样不合理, 比如说觉得这样导致一些字段的获取层次太深了, 或者是你认为把一些字段抽取出来放在一个 Struct 里才更”合理”. 我给的建议是, 不要用 GraphQL 了.

平级和跨级依赖

这是GraphQL 的一个痛点.

比如说, 我们有一个 Atuhor Struct, Author 里面有 photoId 这个字段, 我们需要通过这个字段去取头像(Photo)的具体数据. 也就是说, Photo 依赖 PhotoId.

photoId 是数据库里面一起返回的, 这样没问题. 因为运行到 Photo 绑定的 DataFetcher 的时候, photoId 必然已经存在了, 只要取 source.photoId 就可以.

但是但是, 如果 photoId 不在 DB 里面一个字段, 而是绑定了一个非默认的 DataFetcher. 这样不能用source.photoId. 可以使用上下文(Context)来传递这个数据, 但问题是运行到 Photo 绑定的 DataFetcher 的时候, 因为两个 DataFetcher 是并行的, 这时photoId 可能还没有取到, Context 传过来的数据可能是一个空值.

我只能用 Future 这种东西来处理这个问题, 但是代码又绕又丑. 具体做法是在 Context 里面放一个 Future, 然后在 photoId 的 DataFetcher 里面 Complete, 在 Photo 的 DataFetcher 里面 Apply

我是希望 GraphQL 可以在框架上解决这个问题, 比如说提供类似 source.getPhotoId() 的方法, 他会自动等待 photoId 的 DataFetcher 完成.

上面是说平级的依赖.

跨级的依赖是说上层的上层(或者更上层)里面的属性, 不能方便的拿到, 只能走 Contxt 来传递, 不方便, 在 IDE 里面也很难做到跳转.

尽量使用 DataLoader

如果有批量处理的需求, 使用 DataLoader

手动 Dispatch

TODO

dataLoader 注册名字规范

需要定义一个规范, 大家都按同样的规范来取名字. 但依然不够好, 不方便跳转, 我取一个 DataLoader 的时候, 没办法方便的跳转到他的定义. 也是 GraphQL 的一个痛点.

async

默认执行策略是”异步执行策略”, 但在 DataFetcher 里面要用 Async 包一下才会真正的异步执行.

enum

Schema 里面尽量使用 Enum, 更加语义化, 使用方一眼就能看明白怎么用, 也可以避免一些笔误带来的错误.

GraphQL-Java 框架的不足

依赖

如上面提到的

无奈使用 Context 传递数据

如上面提到的

说在最后

像 JAVA 框架现在还在开发迭代中, 希望他能在框架层面解决一些问题.

另外如果有人能提供 IDE 的插件也可以解决一些问题, 比如说 IDE 里面的跳转. 毕竟更好的语义分析能力的也是大家使用 IDE 的一个重要原因.