Choosing a GraphQL Client: Apollo vs. Relay, 作者 Rachel Lee, 原文来自于codazen的博客

Choosing a GraphQL Client: Apollo vs. Relay

如果你就是想看看二者的对照表, 那就一直往下滑吧, 当然, 希望你这样不会伤到作者的心.

你会看到这篇文章应该是你听闻过了GraphQL, 这一全新的开创性的为你的应用获取数据的方式. 也许你已经搞定如何从零搭建一个GraphQL Server(如果没有, 你可以读读这些棒呆了的文章). 那么现在, 你需要选择一个客户端来使得你崭新的GraphQL Server得以派上用场. 你可能已经听说过Relay并且已经走了一遍教程, 或许你觉得它有点令人困惑或是困难? 并且没有意识到其实你还有其他选择. 实际上, ApolloRelay是目前最领先的两个开源 GraphQL 客户端框架(适用于 NodeJS 应用).

要是有个快速简单的双方对比就好了, 这样你就可以很容易就哪一款客户端框架更适合你作出一个有效的决定, 啊哈, 恭喜你找到了!

为什么需要选择一个 GraphQL Client?

在我们决定使用哪一个客户端框架时, 我们理所应当先讨论讨论, 为什么我们需要一个专用于 GraphQL 的客户端? 为什么不坚持使用原先你正用的舒服的那个? Redux可以和GraphQL协同工作的不错. 如果你想花更多时间来尝试弄明白 GraphQL 内部类似于 Redux 但更符合常理的上下文机制(Context)是如何工作的, 我强烈推荐你阅读James Childs-Maidment’s fantastic article on Getting started with Redux and GraphQL.

然而我们都知道Redux并不是为了最大限度发挥 GraphQL 优势而设计的, 如果你学习 GraphQL 的目标是准备真正的发挥它神奇的优势, 那么在其客户端侧也花时间去做相关工作, 以此来尽可能地利用你的GraphQL Server, 就是理所当然的了.

为了达到这个目标, Apollo 和 Relay 都实现了查询与某种形式的数据缓存, 以此来更好的优化向GraphQL Server发起地请求.

这也就意味着实际上二者已经做了大量工作在预处理/后处理(pre/post-processing)上来达成智能有效的请求发送. 这也是 Redux 不能为你做的. Apollo 和 Relay 还做了很多其他贴心的优化, 以下是一份简洁且有条理的二者的对照表.

对照

ApolloRelay 拥有很多相似的特性, 但是它们并不完全相同, 所以我对它们的差异做了一份分类. 为了使内容简洁, 我会在部分条目加上我认为较为有用的资源链接来提供更多信息.

关键点(Key Values)

Apollo
  • 渐进式的使用方式(译者注, Apollo 允许你只启用很少的一部分功能来实现应用)
  • 易于入门
  • 便于调试与易懂
  • 为交互式应用打造
  • 社区驱动
Relay
  • 声明式使用: 只需要知道什么是数据, 而不用担心如何/何时获取
  • 搭配使用: 在视图层中书写数据依赖
  • 数据变动(Mutations): 数据一致性, 乐观更新以及错误处理

缓存中对象区分(Object Identification for Caching)

Apollo: __typename + id(客户端自动生成)

Relay: graphql-relay 全局 id(由服务端生成, 需要*GraphQL schema configuration*)

查询语言(Query Language)

Apollo: graphql-tag

Relay: Relay.QL

查询批处理(Query Batching)

Apollo: 内置(只需要一行代码来设置与配置)

Relay: react-relay-network-layer

订阅支持(Subscriptions)

Apollo: 支持

Relay: 支持(ish)

片段支持(Fragment)

Apollo: yes

Relay: yes

乐观 UI 更新(Optimistic UI Updates)

Apollo: yes

Relay: yes

分页(Pagination)

Apollo: 对范式(schema)进行任意分页 (服务端), fetchMore API (客户端)

Relay: 基于指针(cursor) (服务端, 需要 GraphQL connections configuration)

自定义网络接口(Custom Network Interfaces)

Apollo: yes

Relay: yes

服务端渲染(SSR)

Apollo: yes

Relay: isomorphic-relay

性能优化(Performance (Caching and Query Optimization))

Apollo: yes

Relay: yes

路由(Routing)

Apollo: react-router

Relay: react-router-relay

单元测试

Apollo: Jest (assuming you’re using React)

Relay: Jest

开发者工具(Developer Tools)

Apollo: Redux DevTools - (谷歌浏览器扩展)

Relay: React DevTools - (谷歌浏览器扩展)

兼容性

Apollo: React, React Native, Angular 2, Redux, Meteor

Relay: React, React Native

学习曲线(至精通)

Apollo: 类似 react-redux

Relay: 全新概念

变动复杂程度(Mutation-Writing Complexity)

Apollo
  • 简单的 GraphQL mutation 与 resolver(这里不翻译, 避免影响理解 GraphQL 语法)
  • 使用 Apollo-Client 发送语义化的 mutation
  • 更新 Apollo-Client 内置的 store
Relay
  • GraphQL mutation, 需要带上客户端变动 ID(WithClientMutationID)
  • 在 GraphQL 与 Relay 间匹配变量名
  • 设置宽松的查询与配置项

文档

Apollo: 详细, 还有图片!

Relay: ...写的一般

开源状态(至 2020-05-05)

Apollo: https://github.com/apollostack/apollo-client

  • Watchers: 313
  • Stars: 13.7k
  • Forks: 1.7k
  • Open Issues: 525
  • Pending PRs: 98

Relay: https://github.com/facebook/relay

  • Watchers: 388

  • Stars: 14.4k

  • Forks: 1.4k

  • Open Issues: 189

  • Pending PRs: 29

尾声

归根结底, 决定权还是在你手里, 并需要根据项目类型来决定. Apollo 提供了更友好的开发者体验和将 GraphQL 接入到已有项目的工作效能. 尤其是在已有项目并非使用 React 的情况下.

而 Relay 则在移动端性能与评测表现上(Facebook 水平上)更有优势.

随着 GraphQL 的继续发展, 二者都有着庞大的社区专注支持自身, 来创建一个更好的网络世界. 所以你不必担心在使用其中之一的过程中出现严重的错误.

我的团队决定采用 Relay, 为什么? Relay 团队一直在努力完善一些主要特性, 并且Relay 的未来看起来也十分不错. 同时, 由于 Relay 和 GraphQL 都是由 Facebook 提出的, 我们认为任何 GraphQL 的更新都会由 Relay 更快的跟进.

现在, 做出你的选择吧: Get started with Apollo or Get started with Relay

如果你需要更多可供阅读的文章, 可以参考上面给出的链接, 它们各自专注于某个特定的关于 GraphQL/Relay/Apollo 的话题. 同时, 也别忘记了关注下一篇介绍 Relay 与 Relay 2 之间的重大更新的文章!