这就是GraphQL超越标准RESTAPI技术的原因。正如我之前所写,GraphQL是下一代API技术,它正在改变客户端应用程序与后端系统通信的方式以及后端系统的设计方式。有了创建它的组织Facebook从一开始的支持,以及Github、Twitter和AirBnB等其他科技巨头的支持,GraphQL作为应用系统关键技术的地位似乎稳固了——无论是现在还是未来。GraphQL的兴起移动应用程序性能和组织敏捷性的重要性日益增加,这推动了GraphQL上升到现代企业架构的顶端。鉴于REST是一种非常流行的架构风格,已经提供了数据交互的机制,那么GraphQL这种新技术与REST相比有什么优势呢?GraphQL中的“QL”代表查询语言,这是一个很好的起点。借助GraphQL,组织内的不同客户端应用程序可以轻松地只查询他们需要的数据,超越其他REST方法,从而提高实际应用程序的性能。使用传统的RESTAPI端点,客户端应用程序将查询服务器资源并接收包含与请求匹配的所有数据的响应。如果来自RESTAPI端点的成功响应返回35个字段,则客户端应用程序将收到35个字段。获取问题传统上,RESTAPI没有为客户端应用程序提供简单的方法来仅检索或更新它们关心的数据。这通常被描述为“过度获取”问题。随着人们日常生活中移动应用程序的广泛使用,过度获取问题可能会在现实世界中产生不良后果。移动应用程序发出的每个请求、接收和发送的每个字节都会对最终用户产生越来越大的性能影响。数据连接速度慢的用户尤其会受到糟糕的API设计的影响。使用移动应用程序体验不佳的客户更有可能不购买产品或使用服务。低效的API设计只会浪费企业资金。不仅“过度访问”是一个问题,“访问不足”也是一个问题。默认情况下,端点仅返回客户端实际需要的部分数据,这需要客户端进行额外的调用来满足其数据需求,从而导致额外的HTTP请求。由于过度获取和获取不足问题及其对客户端应用程序性能的影响,促进高效获取的API技术有机会在市场上引起轰动——GraphQL大胆介入并填补了这一空白。对REST的回应不愿不战而降,RESTAPI设计者已尝试通过多种方式解决移动应用程序性能问题:领域。一种“复合”服务,结合了多个端点,使客户端应用程序在发出的请求数量和接收的数据方面更加高效。虽然这些模式是RESTAPI社区为解决移动客户端面临的挑战而进行的一次英勇尝试,但它们在几个关键方面存在不足:包括和排除查询键/值对很快就会变得混乱,特别是对于需要嵌套用于包含和排除目标数据的“点符号”语法(或类似语法)。此外,在此模型中调试查询字符串问题通常需要手动分解URL。包含和排除查询的服务器实现往往是自定义的,因为基于服务器的应用程序没有处理包含和排除查询使用的标准方法,就像没有定义包含和排除查询的标准方法一样。复合服务的兴起导致后端和前端系统的耦合更加紧密,需要更好的协调来交付项目,并将曾经敏捷的项目转变回瀑布式开发。这种协调和耦合还具有降低组织敏捷性的痛苦副作用。此外,顾名思义,组合服务不是RESTful。GraphQL的由来对于Facebook来说,其在2011-2012年基于HTML5版本的旗舰移动应用程序中感受到的痛点和经验创建了GraphQL。意识到提高性能至关重要,Facebook工程师意识到他们需要一种新的API设计来确保最佳性能。也许考虑到上述REST的局限性,以及支持许多API客户端的不同需求的需要,我们可以理解是什么促使其共同创建者LeeByron和DanSchaeffer(当时是Facebook员工)创造了今天的成果被称为GraphQL技术的早期种子。使用GraphQL查询语言,客户端(通常是单个GraphQL端点)应用程序通常可以显着减少所需的网络调用次数,并确保只检索它需要的数据。在许多方面,这让人回想起早期的Web编程模型,其中客户端应用程序代码将直接查询后端系统——例如,你们中的一些人可能还记得10或15年前在JSP上使用JSTL编写SQL查询场景!现在最大的不同是,有了GraphQL,我们有了一个跨多种客户端和服务器语言和库实现的规范。通过GraphQL这一API技术,我们通过引入GraphQL应用中间层来解耦后端和前端应用系统,该中间层提供了一种以与组织业务领域一致的方式访问组织数据的机制。除了解决软件工程团队遇到的技术挑战外,GraphQL还有助于提高组织敏捷性,尤其是在企业中。支持GraphQL的组织敏捷性通常归因于以下因素:当客户需要一个或多个新字段时,GraphQLAPI设计人员和开发人员无需创建新端点,而是能够将这些字段包含在现有图形实现中,从而以更少的成本公开新功能开发工作量和跨应用程序系统的更少更改。通过鼓励API设计团队更多地关注定义对象图而不是客户端应用程序交付,前端和后端软件团队向客户交付解决方案的速度越来越脱钩。###采用前的注意事项尽管GraphQL具有引人注目的优势,但GraphQL并非没有实施挑战。一些示例包括:为RESTAPI建立的缓存机制更加成熟。使用REST构建API的模式更加完整。虽然工程师可能更喜欢像GraphQL这样的新技术,但市场上的人才库比GraphQL更专注于构建基于REST的解决方案。结论通过同时提高性能和组织敏捷性,GraphQL在过去几年中在企业采用方面呈爆炸式增长。但是,它确实需要比用于API设计的RESTful生态系统更成熟一些。GraphQL的一大优点是它并非设计为替代API解决方案的批发替代品。相反,GraphQL可用于补充或增强现有API。因此,鼓励企业在GraphQL对他们最有意义的地方探索逐步采用GraphQL——他们发现它对应用程序性能和组织敏捷性具有最大的积极影响。
