接上篇 —— 如何使用 GraphQL-基础教程：介绍 —— 继续翻译How to GraphQL 系列教程。
了解为什么 GraphQL 是比 REST API 的更有效，更灵活的替代方案。
具有强类型系统，避免了过度获取和获取不足的前端问题。
基础和进阶系列翻译已完成：
在过去的十年中，REST已成为设计 Web API 的标准（尽管很模糊）。它提供了一些很棒的创意，例如无状态服务和结构化存取资源。但是，REST API 过于灵活，跟不上客户端的快速变化的需求。
开发 GraphQL 就是为了满足对灵活和效率的需求！它解决了开发人员与 REST API 交互时遇到的许多缺点和效率低的问题。
为了说明从 API 提取数据时 REST 和 GraphQL 之间的主要区别，让我们考虑一个简单的示例场景：在博客中，一个应用需要显示特定用户的帖子标题。在同一屏幕上还显示该用户的最后 3 个关注者的名称。REST 和 GraphQL 如何解决这种情况？
💡 查看这篇 博客 来学习更多开发者喜爱 GraphQL 的原因。
数据获取中 REST vs GraphQL
使用 REST API，通常可以通过访问多个端点来收集数据。在示例中，可以是 /users/<id> 端点获取初始用户数据。其次，可能有一个 /users/<id>/posts 端点返回用户的所有帖子。然后，第三个端点将是/users/<id>/followers 返回每个用户的关注者列表。
使用 REST，必须向不同的端点发出三个请求以获取所需的数据。这样还会导致过度获取（overfetching），因为端点会返回不需要的其他信息。
另一方面，在 GraphQL 中，只需将包含具体数据要求的单个查询发送到 GraphQL 服务端。然后，服务端将使用满足这些要求的 JSON 对象进行响应。
使用 GraphQL，客户端可以在 query 中精确指定所需的数据。请注意，服务端响应的 结构（structure） 正好遵循 query 中定义的嵌套结构。
不会过多或过少的获取数据
REST 最常见的问题之一是过度获取和获取不足（over- and underfetching）。这种情况发生的原因是客户端下载数据的唯一方法是访问返回 固定（fixed） 数据结构的端点。来设计 API 时，能够满足客户端确切的数据需求是非常困难的。
“在图（graphs）而不是端点（endpoints）中思考。”Lessons From 4 Years of GraphQL，作者是[Lee Byron]（https://twitter.com/leeb）， GraphQL 联合创造者。
Overfetching：过度获取数据
过度获取（Overfetching）表示客户端下载的信息多于应用中实际需要的信息。例如，假设有一个屏幕仅需要显示带有用户名的用户列表。在 REST API 中，此应用通常会访问 /users 端点并接收带有用户数据的 JSON 数组。但是，此响应可能包含有关返回的用户的更多信息，例如他们的生日或地址，这些都是对客户端无用的信息，因为它只需要显示用户名即可。
获取数据不足和 n+1 问题
另一个问题是获取不足（underfetching） 和 n+1次请求问题。获取不足通常意味着特定的端点无法提供足够的必需信息。客户端将不得不发出其他请求以获取其全部所需数据。这可能会升级为下面的情况：客户端需要首先下载元素列表，但随后需要为每个元素提出一个额外请求以获取所需数据。
例如，考虑到同一应用还需要为每个用户显示最后三个关注者，该 API 提供了附加端点 /users/<user-id>/followers。为了能够显示所需的信息，该应用程序必须向 /users 端点发出一个请求，然后为每个用户访问 /users/<user-id>/followers 端点。
前端的快速生产迭代
REST API 的常见模式是根据应用内部的视图来构造端点。因为它允许客户端通过简单地访问对应的端点来获取特定视图的所有必需信息，所以很便捷。
这种方法的主要缺点是不允许在前端进行快速迭代。每次对 UI 进行更改后，现在都存在比以前需要更多（或更少）数据的高风险。因此，还需要调整后端以解决新数据的需求。这会降低生产效率，并显着降低将用户的反馈整合到产品中的能力。
使用 GraphQL，可以解决此问题。由于 GraphQL 非常灵活，因此无需在服务端进行任何额外工作即可在客户端进行更改。由于客户端可以指定确切的数据要求，因此当前端的设计和数据需求发生变化时，无需后端工程师进行调整。
服务端的深入分析
GraphQL 可以更深入的了解服务端被请求的数据。由于每个客户端都准确指定了感兴趣的信息，因此可以深入了解可用数据的使用方式。例如，这可以帮助改进 API 和弃用任何客户端不再请求的特定字段。
使用 GraphQL，还可以对服务端处理的请求进行低级性能监视。 GraphQL 使用 解析器函数（resolver functions） 的概念来收集客户端请求的数据。对这些解析器的性能进行监测，可以提供关于系统瓶颈的关键分析。
schema 和强类型系统的好处
GraphQL 使用强类型系统定义 API 的功能。使用 GraphQL 模式定义语言（SDL）在 schema 中写下 API 中公开的所有类型。此 schema 充当客户端和服务端之间的协定，来定义客户端如何访问数据。
一旦定义了 schema，前端和后端团队无需进一步的通信就可以进行工作，因为他们俩都知道通过网络发送的数据的确定结构。
前端团队可以通过模拟（mock）所需的数据结构来轻松测试自己的应用。服务端准备就绪后，可以打开客户端开关从真实的 API 中加载数据。
前端记事本，不定期更新，欢迎关注！
