本书的主旨是 GraphQL 在现代应用中的使用。GraphQL 只是一种规范，虽然它可以运用在许多编程语言中，但本书将主要聚焦于 JavaScript 中的 GraphQL。GraphQL 规范的缔造者 Facebook，发布了用 JavaScript 实现 GraphQL 的样例，而用 JavaScript 的原因是：对于许多公司以及他们的客户端服务器架构来说 JavaScript 是近来最备受瞩目的编程语言和生态系统了。

GraphQL 是一种可以用在任何地方的查询语言，但它通常用于客户端与服务器应用间的通讯。它并不局限于网络层协议的使用，所以数据可以在客户端和服务器应用间读写。它用于补足 JavaScript 中各种库和框架的网络协议栈。客户端可以用像 React、Angular、 Vue 等流行的解决方案，而服务端可以在 Node.js 的环境中使用 Express、Koa、 Hapi 等中间件库。有了这些前后端框架，剩下的就只是通过网路发送带有 GraphQL 指令的 HTTP 请求去链接两端了。

GraphQL 的出现开启了 web 开发的新纪元。RESTful 应用是现在业界在客户端与服务器数据传输上最受欢迎的方式，但是现代的需求已经发生了改变。现在许多应用不得不处理多种客户端，比如桌面应用，web 应用，移动端应用，可穿戴设备应用，他们都需要服务端暴露 API。这就变成了两种选择，一种是用 REST 实现多个针对不同客户端的 API，而另一种则是用 GraphQL 实现一个对所有客户端应用都通用的 API，对于该如何选择就不言而喻了。但 GraphQL 不仅仅只是一个统一的接口，随着开源社区的发展，它的生态系统赋予了它强大的功能甚至更多的可能性。

我恰好有幸与一位 Java GraphQL 开源代码的贡献者共事过。他的努力使他成为了首批 GraphQL 开源代码的贡献者之一，并最终构建了可靠的 Java 实现。这段经历塑造了我自己对 GraphQL 的思考，而后当我的雇主为其企业级应用评估 GraphQL 时，又加深了我对它的思考。最初，我们客户端与服务器之间的粘合主要受 REST 的影响，我们拥有适用于所有 RESTful 资源的 API 端点，但最终遇到了问题，像 Facebook 这样的第三方客户端，无法消费我们的 API 。由于 API 端点过于严格，因此需要对它进行聚合和修改。 聚合意味着将更多的资源放入单个 API 端点，而修改则是为了提供 API 端点的变形，以满足对同一个请求资源的不同表示。我们引入了自己实现的方法去服务器请求资源，最终我们实现了简单的 GraphQL。在客户端方面，当时只有 Relay for React 这一个成熟的库按照消费 GraphQL API 来进行发布的，因此我们也投入了时间去研究它。最后，发现 GraphQL 尚处于发展阶段，因此我们推迟了将其引入我们的技术栈的决定。但不可否认，当时的我们都未料到它会变得如此强大且受欢迎。

因为这本书以 GraphQL 在客户端的应用为开端，所以你将使用 React 作为 UI 框架去消费 GraphQL API，被消费的是 GitHub 的 GraphQL API。它之所以能成为开发者们热衷选择的原因是：GitHub 是向公众发布 GraphQL API 的少数几家流行公司之一；GitHub 的稳定增长也为 GraphQL 本身带来了一定的可信度；还有就是第三方 API 通常会在刚开始的时候聚焦于客户端 GraphQL 应用上。此时本书讲授如何在客户端程序中去消费 GraphQL API 而无需你自己去实现一个 GraphQL 的服务器。

当本书内容转向服务器端的 GraphQL 时，我们将实现最终可由 GraphQL 客户端应用程序消费的 GraphQL API。你将实现如身份验证、数据库连接、分页这样强大的功能。最后，你应该能够牢牢掌握如何在 JavaScript 应用中使用 GraphQL 的知识。