为什么要使用GraphQL？

正如我之前所写， GraphQL是下一代API技术，它正在改变客户端应用程序与后端系统的通信方式以及后端系统的设计方式。

由于从创建它的组织Facebook开始获得支持，并得到其他技术巨头（如Github，Twitter和AirBnB）的支持，因此GraphQL作为应用程序系统关键技术的地位似乎是可靠的； 无论现在还是将来。

GraphQL的上升

移动应用程序性能和组织敏捷性重要性的提高为GraphQL登上现代企业体系结构的顶端提供了助推器。

鉴于REST是一种非常流行的体系结构样式，已经允许进行数据交互的机制，与REST相比，这项新技术具有哪些优势？ GraphQL中的“ QL”代表查询语言，这是一个很好的起点。

借助GraphQL，企业中的不同客户端应用程序可以轻松地仅查询所需数据，从而取代了其他REST方法，并提高了实际应用程序的性能。 使用传统的REST API端点，客户端应用程序可以查询服务器资源，并接收包含与请求匹配的所有数据的响应。 如果来自REST API端点的成功响应返回35个字段，则客户端应用程序将接收35个字段

提取问题

传统上， REST API无法为客户端应用程序提供唯一的方法来仅检索或更新他们关心的数据。 通常将其描述为“过度获取”问题。 随着移动应用在人们的日常生活中的普遍使用，过度获取问题产生了现实世界的后果。 移动应用程序需要发出的每个请求，以及它必须发送和接收的每个字节，对最终用户的性能影响越来越大。 数据连接速度较慢的用户尤其会受到次优API设计选择的影响。 使用移动应用程序性能不佳的客户更有可能不购买产品或使用服务。 低效的API设计使公司付出了金钱。

并非只有“过度获取”-它在犯罪方面有伙伴-“欠获取”。 默认情况下，仅返回客户端实际需要的部分数据的端点要求客户端进行其他调用以满足其数据需求-这需要其他HTTP请求。 由于获取过多和获取不足的问题及其对客户端应用程序性能的影响，促进有效获取的API技术有机会在市场上引起轰动-GraphQL大胆地介入并填补了这一空白。

REST的回应

REST API设计人员不愿无休止地失败，他们尝试通过以下多种方式来应对移动应用程序性能问题：

• “ include”和“ exclude”查询参数，允许客户端应用程序通过潜在的长查询格式指定他们想要的字段。
• “综合”服务以使客户端应用程序发出的请求数量和接收的数据效率更高的方式组合了多个端点。

尽管这些模式是REST API社区为解决移动客户端所面临的挑战而做出的英勇尝试，但它们在以下几个关键方面没有实现：

• 包含和排除查询键/值对很快变得混乱，特别是对于需要嵌套点表示法语法（或类似方法）以将数据包含和排除为目标的更深的对象图而言。 此外，在此模型中调试查询字符串的问题通常需要手动分解URL。
• 包含和排除查询的服务器实现通常是自定义的，因为基于服务器的应用程序没有标准方法来处理包含和排除查询的使用，就像没有定义包含和排除查询的标准方法一样。
• 复合服务的兴起创建了更加紧密耦合的后端和前端系统，需要加强协调以交付项目，并将敏捷项目一旦转为瀑布式。 这种协调和耦合具有减慢组织​​敏捷性的痛苦副作用。 此外，根据定义，组合服务不是RESTful。

GraphQL的起源

对于Facebook而言，GraphQL的起源是对疼痛感和体验的回应，这些疼痛感和体验是从其旗舰移动应用程序基于HTML5的版本（2011-2012年）中学到的。 Facebook工程师意识到提高性能至关重要，因此意识到他们需要一种新的API设计来确保最佳性能。 可能考虑到以上REST限制，并需要支持许多API客户端的不同需求，因此人们可以开始了解当时共同创建者Lee Byron和Dan Schaeffer（Facebook员工）的早期种子。创建被称为GraphQL的东西。

使用通常是单个GraphQL端点的客户端，通过GraphQL查询语言，客户端应用程序能够（通常）显着减少所需的网络调用数量，并确保仅检索所需的数据。 在许多方面，这可以追溯到早期的Web编程模型，在该模型中，客户端应用程序代码将直接查询后端系统-例如，有些人可能还记得10到15年前在JSSP上用JSTL编写SQL查询！

现在最大的区别在于GraphQL，我们有一个规范可以在各种客户端和服务器语言以及库中实现。 由于GraphQL是一种API技术，我们通过引入中间的GraphQL应用程序层来分离后端和前端应用程序系统，该层提供了一种以与组织的业务领域相一致的方式访问组织数据的机制。

除了解决软件工程团队遇到的技术挑战之外，GraphQL还促进了组织敏捷性的提高，特别是在企业中。 启用GraphQL的组织敏捷性通常归因于以下因素：

• GraphQL API设计人员和开发人员无需在客户端需要一个或多个新字段时创建新的端点，而是可以将这些字段包含在现有的图形实现中，从而以较少的开发工作量和跨应用程序系统的较少更改的方式公开新功能。
• 通过鼓励API设计团队将更多的精力放在定义对象图上，而不是在专注于客户端应用程序所交付的内容上，前端和后端软件团队为客户交付解决方案的速度日益脱节。

采纳之前的注意事项

尽管GraphQL具有引人注目的优势，但GraphQL仍然面临着实施挑战。 一些示例包括：

• 围绕REST API的缓存机制更加成熟。
• 用于使用REST构建API的模式已经非常完善。
• 尽管工程师可能更喜欢GraphQL等新技术，但与GraphQL相比，市场上的人才库更广泛，可用于构建基于REST的解决方案。

结论

通过同时提高性能和组织敏捷性，GraphQL在公司中的采用在过去几年中猛增。 但是，与RESTful API设计生态系统相比，它确实有一些成熟的工作。

GraphQL的一大优点是，它并不是作为替代API解决方案的批发替代品而设计的。 相反，可以实现GraphQL来补充或增强现有的API。 因此，鼓励公司探索逐步采用GraphQL的方法，使之对他们最有意义-他们发现它对应用程序性能和组织敏捷性具有最大的积极影响。

翻译自: https://opensource.com/article/19/6/why-use-graphql