GraphQL 是一种用于 API 的开源查询语言，可以在一次 API 调用中从多个来源获取数据。 它还充当服务器端运行时，利用现有数据完成查询。 GraphQL 优先向客户端仅提供请求的数据，同时仍提供完整的 API 数据描述，并使得 API 的扩展和发展变得更加容易。
GraphQL 的设计考虑了灵活性、速度和开发人员。 使用 GraphQL，开发人员可以根据自己的需要构建 API，然后使用 GraphQL 规范来确保 API 可供客户端使用。
GraphQL 查询的主要概念之一是您收到的数据是可预测的。 返回的不是多余的代码串，而是所请求的内容。 这种声明性数据获取在带宽有限的移动设备上特别有用。 使用 GraphQL 的应用程序也稳定且快速，因为它们控制请求和接收的数据，而不是服务器。 即使在较慢的网络连接下它们也很快，因为单个请求可以一次返回多个请求的项目。
基于 GraphQL 的数据简化，API 按类型和字段而不是端点进行组织。 这意味着所有数据都可以在单个端点上访问，从而使应用程序只需请求必要的数据。 通过降低操作复杂性，GraphQL 适合简化的API 连接解决方案的工作流程。
2012 年，Meta（当时的 Facebook）需要一个足够强大的数据获取 API，以适应其 Facebook 移动应用。 在 Lee Byron 的领导下，Facebook 开发了 GraphQL，以简化数据获取——具体来说，从产品设计师和开发人员的角度来看。 GraphQL 最初由 Facebook 内部使用，随后于 2015 年公开发布并开源。 与许多其他开源项目的轨迹一样，GraphQL 项目于 2019 年迁移至由Linux 基金会托管的自己的GraphQL 基金会。
GraphQL 被设计为REST架构的替代方案。 标准 REST API 需要通过单独的 HTTP GET 请求从多个 URL 加载信息。 使用 GraphQL API，所有数据都可通过单个 POST 请求检索。 虽然 REST 和 GraphQL 都返回 JSON 格式的响应，但 GraphQL 专注于简化和整合数据。
GraphQL 支持细粒度的数据请求，并让客户端对发送的信息有更多的控制权。 客户端以 POST 请求的形式发送 GraphQL 查询，服务器返回 JSON 格式的响应。 GraphQL 不需要特定的应用架构，可以在多种环境中部署（包括集成开发环境 [IDE]），并且可以与现有的API 管理工具一起使用或在现有的 REST API 之上使用。
GraphQL 中的一些关键术语包括：
GraphQL 的一个独特功能是响应镜像查询的结构（查询本身由模式定义）。 这简化了客户端的解析，因为服务器响应的格式是完全可预测的。
GraphQL 的层次结构特性遵循对象之间的关系，并且在分层用户界面中运行良好。 它也是强类型的，这意味着每个查询级别都匹配一种类型。 然后这些类型定义一组字段。 这类似于 SQL，在完成查询之前会显示描述性错误消息。
解析器是将 GraphQL 字段、边、变异、查询和订阅连接到数据源（和微服务）的关键架构模块。
您可以在此GraphQL 教程中了解如何为 AWS 数据源构建解析器。
GraphQL 查询的独特之处在于镜像响应。 查询返回的数据变得可预测，因为您知道它将与 API 请求的形状匹配。 当返回的数据形状符合客户端查询时，服务器就会变得简化。
GraphQL 的一个主要优点是可以通过扩展来提供 REST 中没有的功能。 GraphQL 的其他优点包括：
GraphQL 模式在 GraphQL应用中设置了单一事实来源，提供了描述所有数据的主要位置。 虽然 GraphQL 模式通常在服务器上定义，但客户端仍然可以根据模式查询和写入数据。
在 REST 架构中，过度获取很快就会成为一个问题：应用（后端）定义每个资源可用的数据并在其响应中返回所有数据，即使客户端（前端）只需要一个元素。 GraphQL 调用在一次行程中完成，并向客户端提供所请求的数据而不会进行任何过度获取。
由于数据类型定义严格，GraphQL 中的客户端和服务器之间的通信比 REST 更清晰。 这种底层结构还意味着不需要复杂的客户端来调用 GraphQL 服务器。 要了解更多信息并查看实际代码，请阅读GraphQL 官方页面上的客户端和服务器内容。
API Federation 是一组设计原则和工具，它可以将有界上下文中的服务公开为用户一致的 API，同时还允许该上下文中的服务不受限制地发展。 GraphQL 提供了一种联合整个 API 的方法，并且在不破坏先前查询的情况下进行改进，从而具有可扩展性——这种可扩展性也是 GraphQL 被许多企业使用的原因之一。
GraphQL 的自省特性支持从 GraphQL API 检索 GraphQL 架构。客户端还可以请求可用数据类型的列表，这对于自动生成文档以及测试或从多个微服务中检索架构非常理想。
虽然采用 GraphQL 有很多理由，但也有一些缺点需要注意。 例如，它并非完全开箱即用——需要特殊库才能使用其他人的 API。而且，总体而言，GraphQL 需要比 REST 更强大的工具支持。
与 REST 相比，GraphQL 的缺点包括以下几点。
对于习惯于 REST API 的开发人员来说，GraphQL 的学习曲线更陡峭。 它还可以改变工作流程——使用 GraphQL 的 API 团队还必须编写可维护的 GraphQL 模式。 也就是说，如果从头开始，GraphQL 很容易学习和使用，因为请求和响应具有相同的结构。
GraphQL 可能需要新的 API 管理策略，而 REST API 往往适合现有的 API 管理模型。 考虑这一点很重要，因为添加新的 API 管理策略可能会增加总体费用。
GraphQL 中的缓存不如 REST 中那么简单，其中请求通常使用 HTTP 方法（GET、POST、PUT 或 DELETE）。 标准 GraphQL 请求是 POST，它不能在 HTTP 级别缓存。 在 GraphQL 中，缓存也会变得复杂，因为只有一个端点意味着该端点的 URL 会产生多个不同的不可缓存响应（适合获取数据，但不利于缓存）。 尽管服务器开发人员都在同一个对象内进行操作，但最终还是会得出不同的查询。 综上所述，许多 GraphQL 库都提供了开箱即用的缓存机制。