GraphQL 是一种 API 查询语言和运行时，用于使用现有数据完成这些查询。它为您的 API 中的数据提供了完整且易于理解的描述，让客户能够准确地询问他们需要什么，更容易随着时间的推移发展 API，并启用强大的开发人员工具。
优点：
- 速度快：使用 GraphQL 的应用程序既快速又稳定，因为它们控制的是获取的数据，而不是服务器。
- 获取许多资源：GraphQL 查询不仅可以访问一种资源的属性，还可以平滑地跟踪它们之间的引用。虽然典型的 REST API 需要从多个 URL 加载，但 GraphQL API 可以在单个请求中获取您的应用程序所需的所有数据。即使在移动网络连接速度较慢的情况下，使用 GraphQL 的应用程序也可以很快。
- 一个端点：GraphQL API 是按照类型和字段组织的，而不是端点。从单个端点访问数据的全部功能。GraphQL 使用类型来确保应用程序只询问什么是可能的，并提供清晰和有用的错误。应用程序可以使用类型来避免编写手动解析代码。
- 可持续性：在不影响现有查询的情况下向 GraphQL API 添加新字段和类型。老化字段可以被弃用并从工具中隐藏。通过使用一个不断发展的版本，GraphQL API 使应用程序能够持续访问新功能，并鼓励使用更简洁、更易于维护的服务器代码。
- 无版本：返回数据的形状完全由客户端的查询决定，因此服务器变得更简单且易于泛化。添加新产品功能时，可以将其他字段添加到服务器，而现有客户端不受影响。当您停止使用旧功能时，相应的服务器字段可能会被弃用，但会继续运行。这种渐进的、向后兼容的过程消除了对递增版本号的需要。我们仍然支持在相同版本的 GraphQL API 上发布三年的 Facebook 应用程序。
- 强类型：GraphQL 查询的每个级别对应一个特定类型，每个类型描述一组可用字段。与 SQL 类似，这允许 GraphQL 在执行查询之前提供描述性错误消息。协议，而不是存储：服务器上的每个 GraphQL 字段都由任意函数支持。虽然 Facebook 正在构建 GraphQL 来支持新闻提要，但他们已经有了一个复杂的提要排名和存储模型，以及现有的数据库和业务逻辑。GraphQL 必须利用所有这些现有工作才能发挥作用，因此不会规定或提供任何后备存储。相反，GraphQL 利用您现有的代码。
- 自省：可以查询 GraphQL 服务器支持的类型。这为工具和客户端软件创建了一个强大的平台，可以在这些信息的基础上构建静态类型语言的代码生成、我们的应用程序框架、Relay 或 GraphiQL 等 IDE .
缺点：
- 无深度查询：GraphQL 不能无深度查询，所以如果你有一棵树并且想在不知道深度的情况下返回一个分支，你必须做一些分页。
- 特定的响应结构：在 GraphQL 中，响应与查询的形状相匹配，因此如果您需要以非常特定的结构进行响应，则必须添加一个转换层来重塑响应。
- 网络级缓存：由于 GraphQL 在 HTTP 上使用的常见方式（单个端点中的 POST），网络级缓存变得困难。解决它的一种方法是使用持久查询。
- 处理文件上传：GraphQL 规范中没有关于文件上传的内容，并且突变不接受参数中的文件。为了解决这个问题，您可以使用其他类型的 API（如 REST）上传文件并将上传文件的 URL 传递给 GraphQL ，或者将文件注入执行上下文，这样您就会在解析器函数中拥有该文件。
- 不可预测的执行：GraphQL 的本质是您可以查询组合您想要的任何字段，但这种灵活性不是免费的。有一些问题值得了解，例如性能和 N+1 查询。
- 超级简单的 API：如果你的服务暴露了一个非常简单的 API，GraphQL 只会增加额外的复杂性，所以一个简单的 REST API 会更好。