正文
你可能会问，我们为什么不能让客户端和服务器端直接通信呢？当然可以。
有多个原因促使我们在客户端和服务器端之间放置一个 GraphQL 层。其中有个原因，可能也是最常见的，那就是效率。客户端通常需要跟服务端要求多个资源，而服务端通常只能理解如何响应单个资源。所以，客户端需要发起多轮请求，这样才能收集到它需要的所有数据。
借助 GraphQL，我们可以将这种多请求的复杂性转移到服务端，让 GraphQL 层来对其进行处理。客户端对 GraphQL 层发起一个请求并且会得到一个响应，该响应中精确包含了客户端所需的内容。
使用 GraphQL 还会有很多收益，比如，另外一个收益就是与多个服务进行通信的时候。如果你有多个客户端要从多个服务请求数据的话，位于中间的 GraphQL 层能够简化和标准化这种通信。尽管这并不是针对 REST API 的（因为它也能很容易地实现），但是 GraphQL 运行时提供了一个结构化和标准化的方式来实现这一点。
图片来源于作者 Pluralsight 课程的截图：使用 GraphQL 构建可扩展的 API
客户端不会与两个不同的数据服务直接交互，我们现在可以让客户端与 GraphQL 层进行通信。然后，GraphQL 层会与两个不同的数据服务进行通信。这样的话，GraphQL 首先能够将客户端进行隔离，这样它们就没有必要使用多种语言进行通信了，同时，GraphQL 还会将一个请求转换为针对不同服务的多个请求，这些不同的服务可能会使用不同的语言编写。
让我们假设有三个不同的人，他们使用不同的语言并且具备不同类型的知识。假设你有一个问题，该问题需要组合这三个人的知识才能给出答案。如果你有一个能够说这三门语言的翻译器，那么为你的问题给出答案就会变得很容易。这其实就是 GraphQL 运行时所做的事情。
计算机还没有足够智能来回答任意的问题（至少目前还不可以），所以它们必须要在某些地方遵循一定的算法。这也是我们需要在 GraphQL 运行时上定义模式的原因，客户端会使用该模式。
基本上来讲，模式就是一个能力文档，它包含了客户端可以请求 GraphQL 层的所有问题的列表。在如何使用模式方面有一定的灵活性，因为我们在这里所讨论的是一个节点图。模式主要体现的是 GraphQL 层所能回答的问题都有哪些限制。
还感到不清楚吗？那我们一针见血地回答 GraphQL 是什么：REST API 的替代品。那么接下来，我们来回答你最可能会提出的一个问题。
REST API 最大的问题在于其多端点的特质。这需要客户端进行多轮请求才能获取到想要的数据。
REST API 通常是端点的集合，其中每个端点代表了一个资源。所以，当客户端需要来自多个资源的数据时，就需要针对 REST API 发起多轮请求，这样才能将客户端所需的数据组合完整。
在 REST API 中，没有客户端请求语言。客户端对服务端返回的数据没有控制权。在这方面，没有语言能够帮助它们实现这一点。更精确地说，客户端可用的语言非常有限。
例如，用来实现读取（READ）的 REST API 一般不外乎如下两种形式：
举例来说，客户端无法指定该选择记录中的哪个字段。这些信息位于 REST API 服务本身之中，不管客户端实际需要哪些字段，REST API 服务始终都会返回所有的字段。GraphQL 对该问题的描述术语是过度加载（over-fetching）不需要的信息。不管是对于客户端还是对于服务器端，这都是网络和内存资源的一种浪费。
REST API 的另外一个大问题是版本化。如果你需要支持多版本的话，通常意味着要有多个端点。在使用和维护这些端点的时候，这通常会导致更多的问题，而这也可能是服务端出现代码重复的原因所在。
上文所述的 REST API 的问题恰好是 GraphQL 所要致力解决的。上面所述的这些肯定不是 REST API 的所有问题，我也不想过多讨论 REST API 是什么，不是什么。我主要讲的是基于资源的 HTTP 端点 API。这些 API 最终都会变成常规 REST 端点和自定义专门端点的混合品，其中自定义的专门端点大多都是因为性能的原因而制作的。在这种情况下，GraphQL 能够提供好得多的方案。
在 GraphQL 背后有着很多理念和设计决策，但是最为重要的包括：
