因为公司需要研究GraphQL并进行学习，所以我将其内容也写在这里。就像写一份报告一样。

GraphQL是什么？

这是Facebook开发的用于Web API的规范。
最初的动机似乎是为了改进Facebook内部API的响应不佳。
详细内容稍后会提及。

历史

最初Facebook是通过一种叫做FQL（Facebook Query Language）的语言来运营Web API的。虽然详细情况不清楚，但它似乎是类似于SQL的语言。

FQL
↓
2012年左右，GraphQL诞生
↓
2015年，GraphQL开源化
↓
2018年11月
GraphQL基金会成立 ←现在就在这里！

为什么诞生？

GraphQL：一种数据查询语言

在上述博客中，描述了GraphQL的产生过程，由Facebook的工程师撰写。

在使用移动应用程序调用API时，应用程序端的期望对象图和API响应的结构不一致。

2012年，我们开始努力重建Facebook的本地移动应用程序。

当时，我们的iOS和Android应用程序是围绕我们的移动网站视图的薄包装器。虽然这使我们接近“一次编写，到处运行”的移动应用程序的理想状态，但实际上它使我们的移动网络视图应用程序超出了其限制。随着Facebook的移动应用程序变得越来越复杂，它们的性能变差，经常崩溃。

在我们过渡到本地实现的模型和视图时，我们第一次发现自己需要一个API数据版本的新闻订阅，这在此之前只能以HTML形式提供。我们评估了向我们的移动应用程序交付新闻订阅数据的选择，包括RESTful服务器资源和FQL表（类似于SQL的Facebook API）。我们对我们想要在应用程序中使用的数据与它们所需的服务器查询之间的差异感到沮丧。我们不认为数据是基于资源URL、二级键或连接表的，我们是根据对象图和我们最终在应用程序中使用的模型（如NSObjects或JSON）来思考数据的。

同时，在服务器端准备数据和客户端解析数据都需要大量的代码编写。这种沮丧激发了我们中的一些人启动了最终成为GraphQL的项目。GraphQL是我们重新思考移动应用程序数据获取的机会，从产品设计师和开发人员的角度出发。它将开发重点放在客户端应用程序上，设计师和开发人员在那里花费他们的时间和注意力。

【译文】

2012年，我们（Facebook）试图对Facebook自家制作的移动应用进行重构。

那个时候，Facebook的iOS/Android应用只是一个包装了移动网站的外壳，几乎没有做任何事情。这在实际上实现了“写一次，运行在任何地方”的纯粹理想，但移动网站实际上已经超越了其限制。随着Facebook移动应用变得越来越复杂，性能变差，经常崩溃。

我们首先着手改进模型和视图，发现新闻推送的API需要一个特定的数据版本，该版本当时只能通过HTML提供。为了在移动应用中接收新闻推送的数据，我们考虑了各种方法，包括从服务器获取数据和使用FQL表（类似于Facebook的SQL API）。然而，渐渐地，我们对我们所需的数据和API服务器所要求的查询之间的差异感到不满意。我们不是将数据视为URL或连接表，而是将其视为对象图和在应用程序中使用的模型，如NSObjects和JSON。

为了提供服务器端的数据并在客户端解析它，我们编写了大量的代码。从这种挫败感中，移动应用开发团队中的几个人发起了这个项目，并最终创造出了GraphQL。
（以下省略）

简而言之，GraphQL的诞生是因为移动应用开发者需要更易用的API服务器，因此创立了新的规范。那么GraphQL最终是如何规定的呢？

GraphQL规范

与SOAP和REST不同，GraphQL是具有描述数据的语言的规范。
它分为”查询语言”和”模式语言”两种类型。
在客户端向服务器发送查询时使用的是查询语言，
在服务器端描述数据结构的是模式语言。

我可以提供一些在官方网站上介绍的例子，无论哪个都可以。以下是一些模式语言的例子。

type Query {
  me: User
}

type User {
  id: ID
  name: String
}

对于这个模式。

function Query_me(request) {
  return request.auth.user;
}

function User_name(user) {
  return user.getName();
}

在客户端端，我们会像下面这样发送查询语言。

{
  me {
    name
  }
}

{
  "me": {
    "name": "Luke Skywalker"
  }
}

什么让人高兴的是，投出的查询和返回的响应的格式几乎完全相匹配。对于REST而言，需要在收到JSON后，预先创建服务器将返回的数据结构体，并进行映射，然后从中提取出实际使用的数据。而在GraphQL中，只需要获取所需数据（在服务器遵循规范的前提下），就可以避免在服务器端修改规范而不必更改客户端逻辑。

请参考

学习GraphQL的完全入门指南─ 从与REST的比较到API和前端的双重实现