GraphQL

简介

一种用于API的查询语言,GraphQL即是一种用于API的查询语言也是一个满足你数据查询的运行时

GraphQL对你API中的数据提供了一套易于理解的完整描述,使得客户端能够准确低获得它需要的数据而且没有任何冗余,也让API更容易随着时间推移而演进,还能构建强大的开发者工具.

GraphQL是一个用于API查询语言,是一个基于使用类型系统来执行查询的服务端运行时(类型系统由你的数据定义).graphQL并没有任何特定数据库或者存储引擎绑定,而是依靠你现有的代码和数据支撑

SQL 指结构化查询语言，全称是 Structured Query Language。
在您的网站中使用 SQL，比如要创建一个显示数据库中数据的网站，您需要：
1、RDBMS 数据库程序（比如 MS Access、SQL Server、MySQL）
2、使用服务器端脚本语言，（比如 PHP 、 ASP、Node）
3、使用 SQL 来获取您想要的数据
4、使用 HTML / CSS

查询语言

GraphQL 作为查询语言似乎是合理的 —— 毕竟 “QL” 似乎重要到出现在名称中。但是我们查询什么呢？看一个示例查询请求和相应的响应可能会有所帮助。

想象一下，客户端应用查询用户详细信息、获取结果，并使用它填充配置屏幕。作为查询语言，GraphQL 的核心优势之一是客户端应用可以只请求它需要的数据，并期望以一致的方式返回这些数据。

那么 GraphQL 响应返回的什么呢？这就是执行引擎发挥的作用，通常是以 GraphQL 服务器的形式出现。

它不依赖任何数据库,且能够和后端数据库一起使用,也可以包括在restfulAPI上

特性

项目的type
type Project {
  name: String
  tagline: String
  contributors: [User] // 数组表示多个，type 为下面的 User
}
type User {
  name: String
  photo: String,
  friends: [User] // User 的朋友们， type 还是 User
}

接下来你可以把GraphQL的查询语言(Queries)当成是没有值只有属性的对象，返回的结果就是有对应值的对象，也就是标准的JSON。

请求你所要的数据 // 基于 Queries
{ // 查找 name 为 GraphQL 的 project
  project(name: "GraphQL") {
    tagline
  }
}
得到可预测的结果
{ // 返回 json
  "project": {
    "tagline": "A query language for APIs"
  }
}

虽然 project 在类型系统里定义了三个字段，但我们(客户端)只需要 tagline 这个字段，服务端就只返回这个字段，而 contributors 里的 User 和其对应字段，本次查询(Query)并不关心。这个 demo 看似简单，其实带来了很多特性~

强类型：GraphQL与 C 和 Java 等后端语言相得益彰，服务端能对响应的形状和性质做出一定保证，而RESTful是弱类型的，缺少机器可读的元数据；
分工：GraphQL让服务端定义好支持哪些Queries，把对数据的Query需求下放到客户端管理，分工明确的同时保持对 API 的聚焦；
分层：GraphQL的Query本身是一组分层的字段，查询就像返回的数据一样，是一种产品(工程师)描述数据和需求的自然方式；(PS：部分翻译的，国外好像都把产品叫做 Product Engineers 而不是 Product Manager。感觉在吐槽的样子)
预测性：GraphQL的Query只返回客户端要求的内容，没有任何冗余(不浪费流量)，而且它只有一个接口地址，由此衍生了另一个特性；
兼容性：需求变动带来的新增字段不影响老客户端，服务端再也不需要版本号了，极大简化了兼容问题；(App 通常是 1-2 周的固定周期发版，在原生应用不强制升级的世界里，会出现用户 1-2 年都不升级的情况。这意味可能同时有 52 个版本的客户端查询我们的服务端，而在 Fackbook 中 GraphQL API 曾支持了横跨 3 年的移动端)
自检性：GraphQL能在执行Query之前(即在开发时)提供描述性错误消息，在给定查询的情况下，工具可以确保其句法是正确有效的，这使得构建高质量的客户端变得更加容易；
Doc & Mock：GraphQL的文档永远和代码同步，开发无需维护散落多处的文档，调用者也无需担心过期问题，而且基于类型系统的强力支撑和 graphql-tools，mocking 会变得无比容易。

链接：https://www.zhihu.com/question/264629587/answer/283187920

缺点

尽管 GraphQL 在其优势方面的劣势可以忽略不计，但我们在这里给出了一些劣势。以下是 GraphQL 的缺点列表：

1. GraphQL 查询复杂度

不要将 GraphQL 误认为是服务器端数据库的替代品。它只是一种简单的查询语言。当请求查询时，服务器执行数据库访问。当我们必须在一个查询中访问多个字段时，无论是在 RESTful 架构还是 GraphQL 中请求，仍然需要从数据源中检索各种资源和字段。因此，当客户端一次请求太多嵌套字段数据时，它也会显示相同的问题。因此，必须有一种机制，如最大查询深度、查询复杂性加权、避免递归或持久查询，以阻止来自客户端的低效请求。

2. GraphQL 缓存

使用 GraphQL 实现简化的缓存比在 REST 中实现更复杂。在 REST API 中，我们使用 URL 访问资源，因此我们可以在资源级别缓存，因为我们将资源 URL 作为标识符。另一方面，在 GraphQL 中，它非常复杂，因为每个查询都可以是不同的，即使它对同一个实体进行操作。但是大多数建立在 GraphQL 之上的库都提供了一种高效的缓存机制。

3. GraphQL 速率限制

GraphQL 的另一个问题是速率限制。在 REST API 中，您可以简单地指定我们在一天内只允许这个数量的请求”，但在 GraphQL 中，很难指定这种类型的语句。