使用GraphQL的五大理由
翻译来自:https://www.prisma.io/blog/top-5-reasons-to-use-graphql-b60cfa683511/
GraphQL正在成为API开发的新标准 - 了解本文中的主要原因。
在仅仅两年半的存在之后，GraphQL已经走到了API开发的最前沿。在本文中，我们解释了为什么开发人员喜欢GraphQL并揭示其快速采用的主要原因。
1）GraphQL API具有强类型模式
大多数API最大的问题之一是他们缺乏与运营相似的强大合同。许多开发人员发现他们需要使用已弃用的API文档，缺乏正确的方法来了解API支持哪些操作以及如何使用它们。
GraphQL架构是每个GraphQL API的支柱。它清楚地定义了API支持的操作（查询，突变和订阅），包括输入参数和可能的响应。架构是一个可靠的合同，它指定了API的功能。
GraphQL架构是一个可靠的合同，它指定了API的功能。
GraphQL模式是强类型的，可以用简单而富有表现力的GraphQL模式定义语言（SDL）编写。由于强大的类型系统，开发人员可以获得许多无模式API无法想象的好处。例如，可以利用构建工具来验证API请求，并检查在编译时与API通信中可能发生的任何错误。您甚至可以在编辑器中获得API操作的自动完成功能！
架构的另一个好处是开发人员不必再手动编写API文档 - 而是可以根据定义API的架构自动生成API文档。这是API开发的改变者！
GraphQL Server基础：模式 - GraphQL服务器的结构和实现（第一部分）
2）没有更多的过度提取和欠缺
开发人员经常描述GraphQL的主要好处，因为客户可以从API中准确地检索他们需要的数据。它们不必依赖返回预定义和固定数据结构的REST端点。相反，客户端可以指定API返回的响应对象的形状。
这解决了REST API常遇到的两个问题：overfetching和underfetching。
使用GraphQL，客户端可以指定API返回的响应对象的形状。
Overfetching意味着客户端正在检索在获取数据时实际上不需要的数据。因此，它会降低应用程序的性能（需要更长时间的下载和解析数据），并且还会耗尽用户的数据计划。
过度获取的一个简单示例如下：一个应用程序为用户显示一个显示用户姓名和生日的个人资料屏幕。提供有关特定用户（.e.g / users / <id>）的信息的相应API端点的设计方式是，它还返回有关每个用户的地址和计费信息。两者对于配置文件屏幕都是无用的，因此不需要获取它们。
欠取与过度获取相反，意味着API响应中不包含足够的数据。这意味着客户端需要提供额外的API请求以满足其当前的数据要求。
在最坏的情况下，欠缺会导致臭名昭着的N + 1请求问题。这描述了客户端需要有关具有n个项目的列表的信息的情况。但是，没有可以满足数据要求的端点。相反，客户端需要为每个元素发出一个请求以收集所需的信息。
例如，考虑一个用户可以发布文章的博客应用程序。该应用程序现在显示用户列表，其中每个用户元素还应显示相应用户发布的上一篇文章的标题。但是，在访问/ usersendpoint以获取列表数据时，不包括该信息。该应用程序现在需要为每个用户向/ users / <id> / articles端点发出一个额外请求，仅获取最新文章的标题。
注意：使用REST API，通常可以通过根据客户端的需求定制API端点的有效负载来解决欠取问题。在该示例中，这意味着/ users端点现在也返回每个用户的最后一篇文章的标题。这种方法起初看起来似乎是一个很好的解决方案，但它阻碍了快速的产品开发和迭代周期，因为应用程序的任何重新设计通常都需要更改后端，这更耗时。在下一节中了解更多信息。
如何使用GraphQL包装REST API - 3步教程如何轻松地将REST API转换为GraphQL API
3）GraphQL实现了快速的产品开发
GraphQL使前端开发人员的生活变得轻松。感谢GraphQL客户端库（如Apollo，Relay或Urql），前端开发人员基本上可以免费获得缓存，实时或乐观UI更新等功能 - 如果不是GraphQL，那么整个团队可以专门为他们工作的领域。
提高前端开发人员的工作效率可以提高产品开发速度。使用GraphQL，可以完全重新设计应用程序的UI，而无需触摸后端。
“我们是产品人员 - 我们设计了用于构建产品的API。”4年GraphQL的经验教训，Lee Byron
构建GraphQL API的过程主要围绕GraphQL架构。因此，您经常会在GraphQL的上下文中听到术语模式驱动的开发。它只是指一个过程，其中首先在模式中定义一个特征，然后用解析器函数实现。
遵循此过程并感谢GraphQL Faker等工具，一旦定义了模式，前端开发人员就可以高效工作。 GraphQL Faker模拟整个GraphQL API（基于其模式定义），因此前端和后端团队可以完全独立工作。
要了解有关架构定义和架构实现之间差异的更多信息，请务必查看本文。
4）编写GraphQL API
模式拼接的想法是GraphQL空间中较新的一种。简而言之，模式拼接允许组合和连接多个GraphQL API并将它们合并为一个。类似于React组件如何由现有组件组成，GraphQL API也可以由现有的GraphQL API组成！
类似于React组件如何由现有组件组成，GraphQL API也可以由现有的GraphQL API组成！
这对于客户端应用程序非常有用，否则这些应用程序需要与多个GraphQL端点通信（这通常可以通过微服务架构或与第三方API（如GitHub，Yelp或Shopify）集成）。由于模式拼接，客户端只处理单个API端点，并且从客户端隐藏了编排与各种服务的通信的所有复杂性。
GraphQL绑定通过启用重用和共享GraphQL API的简单方法，将模式拼接的思想提升到了新的水平。
使用GraphQL绑定重用和组合GraphQL API - 使用GraphQL绑定，您可以将现有的GraphQL API嵌入到GraphQL服务器中。
5）丰富的开源生态系统和令人惊叹的社区
自GraphQL正式发布以来只有两年半的时间了，从那时起整个GraphQL生态系统已经成熟了多少令人难以置信。
当它出现时，开发人员使用GraphQL的唯一工具是graphql-js参考实现，一个Express.js和GraphQL客户端Relay（Classic）的中间件。
今天，GraphQL规范的参考实现以各种语言提供，并且有大量的GraphQL客户端。此外，许多工具（如Prisma，GraphQL Faker，GraphQL Playground，graphql-config等）提供了无缝的工作流程，并在构建GraphQL API时提供了令人惊叹的开发人员体验。