[译] 从 Reddit 讨论中看到的 GraphQL 现状

• 原文地址：The state of GraphQL by Reddit
• 原文做者：Robert Matyszewski
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：TiaossuP
• 校对者：yangxy81118

从 Reddit 讨论中看到的 GraphQL 现状

一提到 GraphQL，就会看到各种炒做文章以及将它与 REST 进行比较的争论。GraphQL 如今处于全球流行、全面使用的早期阶段，没有人确切知道它会在哪里在止步。经过在互联网上的调研，我发现了许多对这项新技术的安利文章。这只是对第一印象的炒做吗？

我研究了 Reddit 上关于 GraphQL 的评论，并挑选了其中一些最受欢迎的内容。本文旨在以透明、客观的态度来讨论这个主题，因此对于每一个派别的不一样观点，我都挑选了一些用户的探讨与争论的内容。下面的每一个评论引用都有一个指向其做者的连接，同时（）中的为该评论的点赞 （译注：原文为 upvote） 数量。不过要注意，我撰写与发表本文之后，点赞数字可能会发生变化。

议程

• 总体情况
• React & Apollo 情况
• 大公司 & GraphQL
• 缓存
• 请求数据
• 总结

总体情况

从总体出发，我选择了两个实践例子。首先，SwiftOneSpeaks 显示了前端开发人员的视角和潜在的市场改进。其次，Scruffles360 展现了团队如何适应 graphql 以及他们使用具体工具的策略趋势。稍后您会发现更多他的评论。第二个评论是本文中选择的赞最少的评论。

SwiftOneSpeaks（23）说：

当我与后端开发团队合做时，他们更倾向于提供新的查询来知足个人需求，由于这不会影响他们必须支持的现有查询。（也就是说，我不知道随着时间的推移，这个查询的扩展性会怎样）。GraphQL 还减小了我必须从新解析为可用（知足个人须要）的数据结构的糟糕响应的数量。（例如，我获得了 3 个数组，我必须将它们关联起来并压缩到一组对象中。尽管后端仍然须要有一些工做要作，但使用 GraphQL，我能够有更丰富的能力来要求数据格式。）

Scruffles360（8）描述了他在 GraphQL 领域内看到的三个发展方向：

• 巨石应用：这就是阿波罗如今所推进的。每家公司都有一个且只有一个 api endpoint 和 schema 代理其余全部东西（principledgraphql.com/）。我完彻底全不一样意这个思路，但不会在这里重复个人论点（若是想了解的话，您能够挖掘个人评论历史）
• 数据库 api：出于一些奇怪的缘由，人们已经开始向数据库添加插件，这些插件能够经过 graphql 直接访问数据库。因为不少缘由，Graphql 很是棒，可是它还不能与原生数据库查询语言相媲美。更重要的是，这去掉了您的业务层，使调用者能够直接访问您的 store。除了一个微服务应用，其他任何人都不该拥有访问store的权限 —— 其余人应该经过您的 api 调用服务。
• 中间路线：经典的 API 作法，每一个应用程序都有本身的 API（在本例中为 GraphQL）。它可能将业务逻辑或代理隔离到微服务（经过 rest 或经过 schema stitching 到另外一个 Graphql 架构）。这是咱们走的路，目前为止还没让我后悔。

React & Apollo 情况

React 和 Apollo 的组合得到了不少关注。此外 Wronglyzorro 和 Livelierepeat 讨论为何后端开发可能不喜欢 GraphQL。一位更有经验的开发人员的回应得到了更多的赞。另外，我选择了一个更长但很是详细的评论。

Wronglyzorro（12）：

咱们在网络应用程序上严格使用 react + apollo。咱们也强迫移动客户端也使用它。虽然听起来有些荒诞，但这确实是大趋势。后端开发人员固然讨厌它，由于他们习惯了本身原有的方式，不喜欢改变。然而，在咱们过去一年中出现的故障中，从没有 GraphQL 致使的，崩溃的老是遗留的后端服务。

Livelierepeat（40）回复：

后端开发人员固然讨厌它，由于他们习惯了本身原有的方式，不喜欢改变。

您可能想要了解个人观点，我曾经是一个年轻的开发人员，使用全部最新的工具，并嘲笑那些「适应不了」的人。我了解到，一般有比「人们讨厌改变」更有趣的缘由。好比 GraphQL 的抽象是否太过复杂？他们抗拒工做量的增长，可究竟增长了什么？

有时，全部的工具都是最新的，反而可能不能让这些工具的效用获得最大凸显。更关键的仍是在于理解代码和参与开发的人。

Capaj （11）的详细总结：

咱们从五月开始在生产环境中使用 GraphQL。咱们是一个全栈团队，因此咱们不须要仰仗合做的后端团队的怜悯。说服每一个人并不容易，不过 GQL 内置了一个示例，每一个人都认为它看起来比 REST 更好。Graphiql 对此有很大帮助。

这挺好的。咱们在后端使用 apollo 引擎，我很是喜欢在生产环境中使用指标捕捉 API 错误。咱们使用 decapi 来装饰咱们的 objection.js DB Model。咱们在单独的地方定义 model，而后不须要作什么就能够自动生成 GQL。

在前端，咱们使用 apollo-client，但到目前为止咱们尚未使用缓存。咱们的前端重点是摆脱以前的 angular.js 代码，因此咱们尚未时间去试验前端缓存。

我还没有使用 apollo 进行客户端状态管理，由于到目前为止我听到的全部反馈都代表它还没有准备好面对生产环境。另外，我不得不说它看起来很啰嗦，写起来也很啰嗦。相反，我但愿我能够扩展 github.com/mhaagens/gq… 并将其用于咱们的状态管理需求。MST 使用 typescript 表现的很好。若是咱们能够在编辑 GQL 查询时动态地从查询中生成 MST 模型，咱们能够大大提升咱们的工做效率。

缓存

我已经从 SwiftOneSpeaks 和 Scruffles360 中看到了不少很棒的和高赞的评论，这些评论已经在上文提到了。如下是他们讨论的缓存问题和潜在解决方案。

SwiftOneSpeaks (23) 写道：

虽然您能够将 GraphQL 配置为以各类方式工做，但实际上它们始终是 POST 请求。这意味着全部依赖于 GET 幂等而 POST 不幂等这一约定的浏览器缓存、CDN 缓存、代理缓存在默认状况下都将失效。一切都被视为新请求。虽然您能够在客户端自行作一些更智能的缓存，但这实际上只是在解决您本身产生（指引入GraphQL）的问题。

Scruffles360 (11) 回复：

阿波罗有一个解决方案 —— 「动态持久化查询」，不过我尚未尝试过。大体来讲，客户端将使用 GET 请求（将 query 哈希），若是失败，则回退到 POST。接下来的 GET 调用将成功并应用到任何代理缓存。

请求数据

这些人还对数据提取提出了不一样的观点。在 graphql-vs-rest （译文在此） 中，做者描述了一个具备多个做者的博客应用程序示例以及使用 GraphQL 与 REST 的可能性。

SwiftOneSpeaks (23) 说：

每一个人都强调「过分请求」问题 （译注：原文为 Over fetching，意指请求的数据中有不少您并不须要的字段。还有一个相似的概念：Under fetching，意指某个接口的返回数据不够，部分字段缺失，致使还须要请求第二个接口，这两种状况的问题都在于浪费了没必要要的网络资源） 问题。我以为这根本不是设计出糟糕服务的借口（事实上问题在于 —— 若是开发者一直很菜，那么他写出来的 GraphQL 服务也不可能就忽然好用了）。这很容易解决，只须要在原有服务前面加一个服务就行 —— GraphQL 能够胜任这项工做，但用别的东西也能够。问题不在因而否过分请求，而是中央服务与解决缓存问题。

Scruffles360（12）回复：

过分请求确实是一个问题。当您有数百个客户端时，每一个客户端都以不一样的方式调用您的系统，则向 rest api 添加一个属性就会致使极大的效率下降。许多人提出为移动客户端和 web 端提供不一样的门面接口，但这样扩展性不好。个人项目由数百个客户端调用，每一个客户端的请求方式与请求内容都有些许不一样。

大公司 & GraphQL

每一个人都对 Facebook、Netflix 和 Coursera 等大公司以及他们对 GraphQL 的使用状况感兴趣。对于这篇 graphql-vs-rest 在 Reddit 中的评论中，咱们能够找到两个主要缘由做为做者 - 状态。提出的第一条评论是我发现的最受欢迎的评论。

• 在 2010 年初，移动用户数量激增，出现了与低功耗设备和缓慢网络相关的一些问题。REST 不是处理这些问题的最佳选择；
• 随着移动使用量的增长，运行客户端应用程序的不一样前端框架和平台的数量也在增长。因为 REST 不够灵活，致使咱们更难开发出一个可以知足全部终端应用需求的单一 API。

Greulich（62）回复这篇文章：

这离题太远，没有意义。构造请求的另外一种方法不会使这些请求所在的网络更好或更差。 我认为做者的描述的是 endpoint 而不是 API，由于任何 endpoint，不管有多少 endpoint，都只是 API 的一部分。假设是这样，为何咱们只须要一个 endpoint？

Scruffles360（16）回复 Greulich：

文章中的前两点措辞并很差，但仍然是正确的。REST API 能够是通用、可复用的，也能够是专门为已知客户端设计。在第一种状况下，当您须要不断再次调用系统以获取更多数据时 （译者注：即上面提到的 Under fetching）（尤为是像10年前咱们在移动设备上那样的高延迟网络），将没法得到良好的性能。若是您为特定客户端制做 API，则显然会遇到可扩展性问题。

总结

在选择正确的评论来总结 GraphQL 的状态时，有不少话要说或选择。直到今天关于 reddit 的最受欢迎的 submissions 是 facebook 或 netflix 的案例研究，但这些 submission 的评论并很少。这给了咱们以 reddit 对 GraphQL 的见解的一个很好的总结。想到各位开发者的平常生活后，我没法忽略 Kdesign（36）写下的内容：

GraphQL 让您的工做更安全，这是确定的。

您必须花时间在前端和实际数据存储之间的全部 N 多层中，寻找数据的位置。

Kollektiv（44）列出了不少GraphQL问题：

• 查询限速和权限评估等很难实现。
• 类型和数据加载器的工做方式，若是不编写完整的 module 就分组查询，则难以有效的方式将查询绑定到数据库层。
• 验证仅检查类型，所以您仍须要某种 JSON schema 来执行其余格式验证。
• GraphQL 查询只容许 left join，所以像 INNER JOIN 加过滤这种从新建立 SQL 就变得很棘手了。
• 来自像 Relay 这样的框架强加的分页（链接）仍是一团糟。

关于我对GraphQL的初步研究 SwiftOneSpeaks（24）写道：

我认为咱们看到了不少「GraphQL 很棒」报告主要是由于任何新服务都很棒 —— 随着时间的推移，由于假设条件被违背 （译注：假设条件的概念能够参考浅谈Architectural Assumption（软件架构设计的假设条件））、需求变动和代码变动，它们确定会变得逐渐笨拙。不过这并不意味着 GraphQL很差 —— 只是说意味着我不能过多地信任早期报告。

最后，我选择了 Mando0975 （28）的观点来总结这篇文章：

开发始终是为工做挑选合适的工具。GraphQL 不是银弹。REST 并无死，GraphQL 也不会杀掉它。

您的 GraphQL 体验如何？

若是发现译文存在错误或其余须要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。