当 Facebook 构建 GraphQL 时，他们需要一个功能强大的数据获取 API，该 API 可以处理 Facebook 的所有任务，但其产品开发人员的学习和使用简单易行。 GraphQL 旨在重建 Facebook 的原生移动应用程序。
GraphQL 是一种查询语言。 它以发送到服务器的字符串形式提供查询。 服务器对查询进行解释，然后将结果以JSON格式返回给客户端。
GraphQL的优点
GraphQL快
GraphQL 比其他通信 API 快得多，因为它可以帮助您通过仅选择要查询的特定字段来减少请求查询。
最适合复杂系统和微服务
我们可以在 GraphQL 的 API 后面集成多个系统。 它统一了它们并隐藏了它们的复杂性。 GraphQL 服务器还用于从现有系统中获取数据并将其打包为 GraphQL 响应格式。 这对于规模庞大且难以维护和处理的遗留基础设施或第三方 API 最为有利。
当我们必须从单体后端应用程序迁移到微服务架构时，GraphQL API 可以通过将多个微服务合并到一个 GraphQL 模式来帮助我们处理它们之间的通信。
没有过度获取和获取不足的问题
GraphQl 相对于 REST 的主要优势在于 REST 响应包含太多数据或有时数据不足，这会产生对另一个请求的需求。 GraphQL 通过在单个请求中仅获取准确和特定的数据来解决这个问题。
简单明了的层次结构
GraphQL 遵循分层结构，其中对象之间的关系在图形结构中定义。 在这里，每个对象类型代表一个组件，从一个对象类型到另一个对象类型的每个关系字段代表一个组件包装另一个组件。
自定义数据形状
当我们向服务器请求 GraphQL 查询时，服务器会以简单、安全且可预测的形式返回响应。 因此，它有助于您根据您的要求编写特定的查询。 这使得 GraphQL 非常容易学习和使用。
代码共享
我们可以在更高的组件级别共享多个查询中使用的 GraphQL 字段以供重用。 此功能称为片段，允许您在保留相同架构字段的同时获取不同的数据。
强类型
GraphQL 是一种强类型语言，其中 GraphQL 查询的每个级别对应于特定类型，并且每个类型描述一组可用字段。 因此，它类似于 SQL，并在执行查询之前提供描述性错误消息。
协议，而不是存储
任意函数支持服务器上的 GraphQL 字段。 它们不规定或提供任何后备存储。 相反，GraphQL 利用您现有的代码。
内省
我们可以查询 GraphQL 服务器的支持类型。 它为工具和客户端软件（例如应用程序框架、Relay 或 GraphiQL 等 IDE）创建了一个强大的平台。 GraphiQL 有助于开发人员快速学习和探索 API。
不需要最新版本
在GraphQL中，根据客户端的查询，结果集或者返回的数据是非常具体的，所以； 服务器对其进行泛化非常简单和容易。 当我们向服务器添加新的产品功能、附加字段时，它们不会影响现有客户端。 您可以毫无顾虑地使用旧服务器，因为服务器字段可能会被弃用但仍可继续运行。 此兼容过程不需要递增版本号。 您可以看到 Facebook 在他们的应用程序中使用了相同版本的 GraphQL API。
GraphQL的缺点
尽管 GraphQL 的缺点与其优点相比可以忽略不计，但我们在这里给出了一些缺点。 以下是 GraphQL 的缺点列表：
GraphQL 查询复杂度
不要将 GraphQL 误认为是服务器端数据库的替代品。 它只是一种简单的查询语言。 当请求查询时，服务器执行数据库访问。 当我们必须在一个查询中访问多个字段时，无论是在 RESTful 架构还是 GraphQL 中请求，仍然需要从数据源中检索各种资源和字段。 因此，当客户端一次请求太多嵌套字段数据时，它也会显示相同的问题。 因此必须有一种机制，如最大查询深度、查询复杂度加权、避免递归或持久查询，以阻止来自客户端的低效请求。
GraphQL Caching
使用 GraphQL 实现简化的缓存比在 REST 中实现更复杂。 在 REST API 中，我们通过 URL 访问资源，因此我们可以在资源级别缓存，因为我们将资源 URL 作为标识符。 另一方面，在 GraphQL 中，它非常复杂，因为每个查询都可能不同，即使它对同一实体进行操作。 但是大多数构建在 GraphQL 之上的库都提供了一种高效的缓存机制。
GraphQL 速率限制
GraphQL 的另一个问题是速率限制。 在 REST API 中，你可以简单地指定我们一天只允许这个数量的请求”，但在 GraphQL 中，很难指定这种类型的语句。
本文英文原版来自：www.javatpoint.com/graphql-adv…
