为什么使用 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 社区为解决移动客户端面临的挑战所做的英勇尝试，但它们在几个关键方面仍然不足，即

• Include 和 exclude 查询键/值对很快变得混乱，特别是对于需要嵌套点表示法语法（或类似语法）来定位要包含和排除的数据的更深层次的对象图。  此外，在此模型中调试查询字符串问题通常需要手动分解 URL。
• Include 和 exclude 查询的服务器实现通常是自定义的，因为没有标准的服务器端应用程序处理 include 和 exclude 查询使用的方式，就像没有标准的 include 和 exclude 查询定义方式一样。
• 复合服务的兴起导致后端和前端系统之间的耦合更加紧密，需要越来越多的协调来交付项目，并将曾经敏捷的项目重新变为瀑布式。  这种协调和耦合具有减缓组织敏捷性的痛苦副作用。  此外，复合服务从定义上来说不是 RESTful 的。

GraphQL 的起源

对于 Facebook 来说，GraphQL 的起源是对 2011-2012 年基于 HTML5 版本的旗舰移动应用程序的痛点和经验教训的回应。  Facebook 工程师意识到提高性能至关重要，他们需要一种新的 API 设计来确保最佳性能。  考虑到上述 REST 的局限性，并且需要支持许多 API 客户端的不同需求，人们可以开始理解早期导致联合创始人 Lee Byron 和 Dan Schaeffer（当时是 Facebook 员工）创建后来被称为 GraphQL 的技术的种子。  

通过通常是单个 GraphQL 端点，通过 GraphQL 查询语言，客户端应用程序能够减少（通常是显着地减少）它们需要发出的网络调用次数，并确保它们仅检索所需的数据。  在许多方面，这让人回想起早期的 Web 编程模型，客户端应用程序代码将直接查询后端系统——有些人可能还记得 10-15 年前使用 JSTL 在 JSP 上编写 SQL 查询！  

现在最大的不同是，对于 GraphQL，我们有一个规范，该规范在各种客户端和服务器语言和库中实现。  并且由于 GraphQL 是一种 API 技术，我们通过引入中间 GraphQL 应用程序层来解耦后端和前端应用程序系统，该应用程序层提供了一种以符合组织业务领域的方式访问组织数据的机制。



除了解决软件工程团队遇到的技术挑战外，GraphQL 还促进了组织敏捷性，尤其是在企业中。  GraphQL 赋能的组织敏捷性提升通常归因于以下几点：

• 当客户端需要 1 个或多个新字段时，GraphQL API 设计者和开发人员无需创建新端点，而是能够将这些字段包含在现有的图形实现中，以一种需要更少开发工作量和更少跨应用程序系统更改的方式公开新功能。
• 通过鼓励 API 设计团队更多地关注定义他们的对象图，而较少关注客户端应用程序交付的内容，前端和后端软件团队为客户交付解决方案的速度越来越解耦。

采用前的考虑因素

尽管 GraphQL 具有引人注目的优势，但 GraphQL 并非没有实施挑战。  一些例子包括：

• 围绕 REST API 的缓存机制更加成熟。
• 使用 REST 构建 API 的模式更加成熟。
• 虽然工程师可能更喜欢像 GraphQL 这样的新技术，但市场上构建基于 REST 的解决方案的人才库比 GraphQL 更广泛。

结论

通过提高性能和组织敏捷性，GraphQL 在过去几年中被公司采用的数量激增。 但是，与 RESTful API 设计生态系统相比，它还有一些成熟之处。

GraphQL 的一大优势在于，它并非被设计为完全替代其他 API 解决方案。 相反，可以实施 GraphQL 以补充或增强现有 API。  因此，鼓励公司逐步探索在最适合他们的地方采用 GraphQL——在他们发现 GraphQL 对应用程序性能和组织敏捷性产生最大积极影响的地方。