前端了解一下GraphQL-轻识

1. GraphQL的兴起

当今构建API的最佳方式是什么?你可能会想到REST，但是如果你打算投资构建新的软件，那么可能值得考虑一些不同的选项，并从中选择最好的。GraphQL作为REST API架构的替代方案脱颖而出，主要（但不只是）是因为它通过设计提供了一个可发现的API。它还带有自己的查询语言和运行时，用于通过称为“解析器”的函数来执行查询。

GraphQL最初是Facebook在2012年开发的，作为动力不足的移动设备更好的数据获取解决方案，2015年开源。2018年，它被转移到Linux基金会的管理下，该基金会维护着其他重要的项目，如Node.js、Kubernetes，当然还有Linux本身。

希望采用GraphQL的人普遍感到鼓舞。例如，从Stack Overflow Trends^[1]可以看出，近几年来它的流行迅速上升。在PayPal、Netflix和Coursera等知名公司也有一些成功的案例，GraphQL在大型复杂架构中构建灵活、高性能的API方面发挥了重要作用。

然而，鉴于我们今天所处的动态技术环境，你的怀疑是可以原谅的。GraphQL会成为另一种潮流吗？如果它对这些公司有效，是否就一定对你有效？让我们讨论一下GraphQL的优点和挑战，以便你能够做出明智的决定。

2. 使用GraphQL的理由

作为一种为灵活性而设计的API技术，GraphQL对于API的开发者和消费者以及其背后的组织来说都是一个强有力的推动者。在本节中，我们将探讨GraphQL的一些关键领域。

2.1. One Data Graph for All

对于拥有多个团队和系统，希望通过一个统一的API轻松获得其数据的组织而言，GraphQL是一个绝佳的选择。

无论你使用了多少数据库、服务、遗留系统和第三方api, GraphQL都可以通过提供客户机可以与之通信的单一端点来隐藏这种复杂性。GraphQL服务器负责从正确的位置获取数据，并且客户端永远不需要知道不同数据来自何处的详细信息。因此，在为客户和内部用户轻松提供数据时，GraphQL生态系统提供了最大的灵活性。

2.2. 没有过度获取或不足获取

对于GraphQL API客户来说，另一个巨大的好处是他们可以准确地请求他们所需要的数据，甚至跨相关实体。这一点尤为重要，因为不同的客户有不同的数据需求，或者因为不同的业务逻辑，或者因为他们只是呈现了不同的数据视图（例如，Web与移动），也可能有不同的硬件限制。

通过比较，从REST API有效地检索重要数据要困难得多。从单个端点请求数据往往会返回比实际需要的更多的数据（超取），而请求几个相关实体的数据通常需要多次调用API（欠取）或为特定的客户端请求提供专门的端点（重复劳动）。GraphQL通过准确地提供每个客户端请求的数据来解决此问题，仅此而已。

2.3. 更好的开发人员体验

GraphQL生态系统附带许多工具，使使用GraphQL变得轻而易举。像GraphiQL和GraphQL Playground这样的工具提供了丰富的体验，允许开发人员以最小的努力检查和尝试API，这要归功于我们将在下一节中讨论的自我文档化特性。

另外，像GraphQL Code Generator^[2]这样的代码生成工具可以用来进一步加快开发速度，而其他工具和最佳实践也可以用来解决具体问题，包括：

客户端缓存在几个客户端库中是开箱即用的。
基于游标的分页（Cursor-based pagination^[3]）提供了一种跨数据列表提供分页的方法。
DataLoader^[4]通过批处理数据提取请求来提高性能，并且还提供了服务器端缓存的基本级别。

2.4. 更高质量的系统

GraphQL API是围绕着类型系统构建的，它列出了每个字段的名称和类型，以及不同实体之间的关系。这种类型的系统或架构用于验证客户端发送的查询。schema可以通过一个叫做自省（introspection）的功能进行查询，自省通常用于生成文档和代码，这些文档和代码将在客户端集成API时使用。

因此，使用GraphQL时，只需花费最少的精力即可获得文档齐全的API。这为第一次使用API的开发者提供了极大的透明度，使开发更加顺利和高效。

2.5. 为变化而建

REST APIs提供同一API的多个版本是很常见的，这样就可以在不破坏现有功能的情况下进行更改。GraphQL鼓励使用另一种API修改方法：演进。

当需要进行突破性的改变时（例如，当重命名一个字段或改变它的类型时），你可以引入一个新的字段并废弃旧的字段，可能在以后当你确定它不再被使用时完全删除它。这意味着你仍然可以改变你的API，同时保持向后的兼容性和单一的API。

3. 采用GraphQL之前的注意事项

GraphQL是构建可扩展和灵活的API的优秀工具，但它不是万能的，当然也不是每个人都适合。

3.1 学习曲线

REST是一种简单而熟悉的API构建方法，而GraphQL则完全不同。开发人员和基础架构工程师都需要学习如何有效地开发和部署GraphQL API，这是一项需要适应的任务。

因此，时间紧凑的团队可能更适合使用他们已经熟悉的技术。

3.2 基础架构和工具

部署GraphQL，尤其是大规模部署，可能需要在基础设施和工具上进行大量投资。使用它并不能让你省去部署虚拟机或容器、设置网络基础架构，以及在大型环境中部署和维护GraphQL服务器软件。

3.3 性能与安全性

你还必须格外小心，GraphQL提供的额外灵活性不会导致恶意或意外地降低或关闭你的系统的查询。这可以通过限制或限制查询复杂性和深度来解决。

最后，保护不应该公开的数据始终很重要。在其他网络技术中流行的认证和授权机制也可以使用GraphQL。此外，请注意内省，因为如果没有正确保护，它可能泄漏内部类型。

总结

毫无疑问，REST可以完成工作，但如果你正处于需要一种更好的方式来构建API并为不同的客户提供服务的阶段，那么你可能应该尝试一下GraphQL。

GraphQL允许你构建可进化和可查询的API，隐藏用于检索各种数据的内部系统的复杂性，并利用类型系统，从而实现自动和最新的API文档。这些功能以及它的工具和生态系统，使GraphQL成为API和客户端开发者的一个高效和有效的工具。

虽然GraphQL确实需要一些投资，但在有大量数据和服务的情况下，它的优势远远超过了现有的和未来的API客户端的访问。

粉丝福利

临走前留下，今天的福利
福利1：《MongoDB 4.0从入门到达人》获取资源请在公众号对话框中回复关键字：043，如果没有关注请扫下面的二维码。更多福利资料请查看公众号菜单
福利2：在看+留言，我随机抽取一位认真留言的小伙伴，给他发一个红包奖励

参考资料

[1]

Stack Overflow Trends: https://insights.stackoverflow.com/trends?tags=graphql

[2]

GraphQL Code Generator: https://graphql-code-generator.com/

[3]

Cursor-based pagination: https://relay.dev/graphql/connections.htm

[4]

DataLoader: https://github.com/graphql/dataloader

前端了解一下GraphQL