哈Ha！
几天前我们提供给翻译的Alex Banks和Eva Porsello的
书将为您简要介绍GraphQL查询语言。 同一作者的关于
React和Redux的书成为真正的畅销书（我们正在等待印刷厂进行第五次印刷）。 顺便说一句，感谢所有向我们指出代码和术语不正确之处的人；）我们将有关过时技术的书作得太快了。
今天的文章Robin Viruch的作者还正在编写一本有关该语言的GraphQL和库的书，并且在今天的文章中简要解释了GraphQL作为REST替代品的优势和特点
当涉及到客户端和服务器应用程序之间的网络请求时，REST通常被选作客户端和服务器世界之间的桥梁。 在REST中，一切都围绕着“我们需要可通过URL访问的资源”的思想发展。 您可以使用
HTTP GET读取资源，使用
HTTP POST请求创建资源，以及使用
HTTP PUT和
DELETE请求更新和删除资源。 这些操作称为CRUD（创建，读取，更新，删除）。 该资源可以是从作者，用户或文章中获取的任何内容。 使用REST时，数据传输格式不是硬编码的，但是最常见的是JSON用于此目的。 最后，REST使用URL和HTTP方法通过常规HTTP协议启用应用程序之间的通信。
尽管REST在相当长的一段时间内一直是事实上的标准，但近年来，Facebook开发的另一项技术已普及：它称为GraphQL。 本文是GraphQL的简介，讨论了此查询语言的优缺点。
什么是GraphQL？在深入讨论GraphQL的优缺点之前，让我们首先回答以下问题：什么是GraphQL？ GraphQL是Facebook在2012年创建的一种免费软件
查询语言 。 甚至在将该产品提交给开源之前，该语言就已经在Facebook上用作内部技术，用于处理移动应用程序。 为什么使用移动应用程序？ GraphQL被开发为典型REST体系结构的替代方案。 它只允许客户端请求所需的数据-不多也不少。 客户负责一切，也就是您。 在这种情况下，REST体系结构中会出现困难，因为数据库接口决定了每个URL上的每个资源可以使用哪些信息。 客户端不需要数据采样。 因此，无论如何，前端都应该请求有关资源的所有信息，即使它只需要一部分数据。 这个问题称为“重新采样”。 在最坏的情况下，客户端应用程序不仅必须读取一个资源，而且还必须读取许多资源，以便执行许多网络请求时必须访问该资源。 这不仅导致重新采样，而且导致网络上类似雪崩的请求。 但是，拥有不仅在服务器上而且还在客户端使用的诸如GraphQL这样的查询语言，客户端可以决定自己需要的数据-为此，它仅向服务器发送一个请求。 当Facebook使用GraphQL语言开发移动应用程序时，可以大大减少网络负载，因为开始通过它传输的数据要少得多。
Facebook免费发布了GraphQL规范及其使用JavaScript的参考实现。 从那时起，该规范已以许多其他主要编程语言实现。 此外，围绕GraphQL开发的生态系统不仅横向扩展，扩散到其他编程语言，而且纵向扩展（库建立在GraphQL之上，例如Apollo，Relay）。
GraphQL提供以下类型的操作：请求（读取），更改（写入）或预订（连续读取）。 这些操作中的任何一个都只是一个字符串，必须根据GraphQL查询语言的规范进行组装。 一旦这样的GraphQL操作从客户端应用程序到达数据库应用程序，就可以与位于后端的整个GraphQL模式进行比较，并使用可用数据为客户端应用程序解析它。 GraphQL与任何网络层（通常通过HTTP组织）以及任何有效负载格式（通常为JSON）都可以很好地兼容。 他还完全“不关心”应用程序体系结构（在大多数情况下，该体系结构由客户端部分和数据库接口组成）。 它只是一种查询语言。
如您所见，该查询已经适用于许多资源（作者，文章），在GraphQL中称为字段，并且仅针对这些字段（即名称，文章的urlSlug）使用一组特定的嵌套字段（尽管可以在GraphQL数据方案本身中提供其他数据）信息（例如，文章-说明，发布日期）。 在REST体系结构中，我们至少需要两个级联查询来检索作者和该作者的文章，而GraphQL可以在一个查询中解决此问题。 另外，查询仅选择必要的字段，而不选择整个实体。
这是GraphQL的本质。 如果服务器应用程序提供了GraphQL架构，在其中定义了所有可用数据及其层次结构和类型，则客户端应用程序仅请求其所需的数据。
GraphQL的好处以下是在应用程序中使用GraphQL的主要好处。
声明式数据采样如您所见，GraphQL在其查询中使用声明性数据采样。 客户端选择数据，其实体以及所有字段之间的各种关系，为此，将应用单个请求。 客户端决定此UI需要哪些字段。 通常，您几乎可以谈论面向UI的数据采样。 例如，这就是Airbnb使用GraphQL的方式。 Airbnb搜索引擎通常会提供针对特定主题领域的房屋，印象和其他类别的结果。 要一次性提取所有数据，将执行GraphQL查询，仅提取特定UI中绝对需要的信息。 最后，GraphQL的职责划分非常有条理：客户端了解数据需求，服务器了解数据结构以及如何从现有来源（数据库，微服务，第三方API）解析数据。
使用GraphQL时无需重新采样使用GraphQL时，没有重新选择。 而移动客户端可能会使用与具有REST-API的Web客户端相同的API进行重新获取。 使用GraphQL时，移动客户端和Web客户端可以使用相同的GraphQL API为自己选择不同的字段组。 因此，移动客户端可以选择较少的信息，因为在小屏幕上可能不需要不必要的信息（与从中查看应用程序的Web版本的大监视器不同）。 GraphQL最大限度地减少了通过网络传输的数据量，有选择地选择它们，在这种情况下，主要由客户端应用程序的需求来指导。
用于React，Angular，Node等的GraphQLGraphQL不仅对React开发人员来说是一个有前途的解决方案。 让它胜过GraphQL的是Facebook，而在客户端，Facebook使用React，实际上，这种语言与前端或后端的任何解决方案均无关。 GraphQL的参考实现是用JavaScript编写的，因此GraphQL可以在客户端和服务器部分与Angular，Vue，Express，Hapi，Koa和其他JavaScript库结合使用。 而且，这不仅适用于JavaScript生态系统。 GraphQL在一个方面模仿REST，因此变得很流行：GraphQL接口独立于用于传达两个对象（例如，客户端和服务器）的编程语言（查询语言）。 因此，可以用任何编程语言来复制其规范。
谁使用GraphQL？自2012年以来，Facebook一直在使用GraphQL，直到该语言成为开源为止。 Facebook是负责开发GraphQL规范及其在JavaScript中的参考实现的驱动力。 因此，使用GraphQL，您已经站在巨人的肩膀上。 但是，其他知名公司在其应用程序中也使用此语言。 他们投资GraphQL生态系统，因为现代应用程序非常需要这种语言。 因此，您不仅会受到Facebook的支持，还会受到以下公司的支持：
当Facebook开发GraphQL并将其公开发布时，其他移动应用程序公司也面临类似的问题。 这就是Netflix创建Falcor项目的方式，该项目可以视为GraphQL的替代方案。 这再次证实对于现代应用程序，您确实需要诸如GraphQL和Falcor之类的解决方案。
真理的唯一来源在GraphQL应用程序中，存在最终的真理：这就是GraphQL模式。 她-中央来源，描述了所有可用数据。 GraphQL模式通常在服务器端定义，而客户端可以基于此模式读取（查询）和写入（修改）数据。 因此，服务器应用程序实质上提供了服务器上可用的详尽信息，并且客户端仅通过在GraphQL中制定查询来询问什么，或者使用GraphQL中的更改来更改较小的信息片段。
GraphQL遵循当前趋势GraphQL遵循应用程序开发中的当前趋势。 后端上只能有一个应用程序，但是经常会发生许多不同的客户端使用该后端（Web客户端，移动设备，智能手表等）的情况，所有这些客户端都依赖于存储在后端应用程序中的数据。 因此，GraphQL不仅可以帮助结交“两个世界”的朋友，而且可以满足每个客户端的要求（例如，与使用网络相关，嵌套数据关系，仅选择所需数据），而无需为每种类型的客户端创建专用的API。
另一方面，在服务器上，我们期望的不是单个内部接口，而是一组微服务，每个微服务都提供自己的特定功能。 在这种情况下，GraphQL方案非常适合，其结构应使在这样的GraphQL方案中可以汇总所有功能。
GraphQL模式如何拼接借助缝合，您可以将许多其他方案组合在一起。 我什么时候可以进入这种情况？ 假设您的后端是使用微服务架构实现的。 每个微服务都处理与特定主题领域相关的业务逻辑和数据。 因此，每个微服务都可以定义自己的GraphQL模式。 之后，您将需要将它们缝在一起以组装客户端应用程序将访问的所有方案之一。 最后，每个微服务可能都有自己的GraphQL终端，一个GraphQL API网关会将所有方案整合为一个全局方案，以提供给客户端应用程序。
内省GraphQLGraphQL自省是使用GraphQL API提取GraphQL模式的功能。 由于该架构包含有关通过GraphQL API可用的所有数据的所有信息，因此可以将其成功用于自动生成API文档。 但是，问题不仅限于记录API。 自省还可用于在客户端应用程序上模拟GraphQL模式（出于测试目的）或从多个微服务检索模式，然后将它们组合在一起。
强类型GraphQLGraphQL是一种用GraphQL的表达性架构定义语言（SDL）编写的高度类型的查询语言。 该语言具有与任何强类型编程语言相同的优点。 它不易出错，可以在编译时进行验证，并且可以指望与支持的IDE /编辑器功能（例如自动完成和输入支持）集成。
GraphQL版本控制GraphQL没有我们在REST中常用的API版本。 在REST中，通常会提供相同API的多个版本（例如api.domain.com/v1/、api.domain.com/v2/），因为资源或其结构会随着时间而变化。 在GraphQL中，您可以在字段级别将API转换为非推荐的API。 因此，客户端在访问非推荐字段时会收到警告。 一段时间后，可以将非推荐字段从方案中排除，然后不再有客户使用它。 因此，可以开发GraphQL API，而无需进行版本控制。
不断发展的GraphQL生态系统GraphQL生态系统正在增长。 这不仅涉及与与GraphQL的强类型化特性有关的编辑器和IDE的集成； 对于GraphQL来说，有一些新的成熟应用程序。 例如，您可以回忆起使用REST API时使用的Postman，现在出于相同的目的，但使用GraphQL API时使用了GraphiQL或GraphQL Playground。 还有许多适合您的库，例如Gatsby.js，这是使用GraphQL的React静态网站生成器。 例如，Gatsby.js允许您编写博客引擎，该引擎通过GraphQL API在构建过程中为博客填充内容。 因此，您还将拥有不带客户端部分（例如GraphCMS）通过GraphQL提供内容（用于博客）的CMS。 API 但是，不仅技术组件正在这一领域发展。 随着雨后蘑菇的生长，致力于GraphQL的会议，混搭和社区也很容易在其中找到时事通讯和播客。
如果我切换到GraphQL-我会全力以赴吗？当然，将GraphQL添加到现有技术堆栈中，我们不会全力以赴。 从单块后端应用程序迁移到微服务体系结构，最重要的是用GraphQL API替代新的微服务。 确实，正是在存在许多微服务的情况下，您和您的团队才可以安全地实现GraphQL网关，拼接方案并将它们整合为一个全局方案。 但是API网关不仅可以与微服务一起使用，而且还可以与整体式REST应用程序一起使用。 这是您可以在一个网关上组合所有API并逐步迁移到GraphQL的方式。
GraphQL的缺点接下来，我们讨论与使用GraphQL相关的一些缺点。
GraphQL查询复杂度有时GraphQL的使用不正确，我尝试将其替换为服务器端数据库。 不，那不会。 GraphQL只是一种查询语言。 当在服务器端需要使用数据来解决请求时，通常有一个与GraphQL无关的实现可提供对数据库的访问。 在这种情况下，GraphQL无关紧要。 此外，当您需要在一个查询中处理很多字段（作者，文章，评论）时，GraphQL并不能消除任何性能瓶颈。 无论发出请求的架构是RESTful还是GraphQL，您仍然必须从源中提取各种字段。
因此，如果客户端立即向嵌套字段集发送一堆请求，我们将遇到问题。 通常，客户端开发人员不知道如果开始大量数据调用，则服务器应用程序中必须处理多少个不同的数据库查询。 在这种情况下，需要一种机制（例如，最大查询深度，权衡查询的复杂性，避免递归，常量查询），以防止来自客户端的过于昂贵的查询流。
GraphQL中的速度限制另一个问题是速度限制。 尽管在REST中说“每天允许的查询数量不超过”相对简单，但是很难为单个GraphQL操作制定这样的指令，因为不仅存在“成本高”和“成本不高”的操作，而且还有许多中间等级。 在这种情况下，
提供公共GraphQL API的公司
提供了自己的速度限制计算 ，通常将
速度限制减小为上述查询深度的最大值和查询复杂度的权重。
GraphQL缓存使用GraphQL时，实现简化的缓存比REST中要复杂得多。 使用REST时，我们通过URL访问资源，因此，由于资源URL可以用作其标识符，因此可以在资源级别组织缓存。 在GraphQL中，这很复杂，因为即使每个人都在同一个对象上操作，所有查询也可能不同。 在一个请求中，您可以请求作者的姓名，在下一个请求中，不仅可以要求作者的姓名，还可以要求他的电子邮件地址。 在这种情况下，您将需要在字段级别使用更多的细丝缓存，并且实现起来并非如此简单。 但是，大多数基于GraphQL构建的库都提供了开箱即用的这种缓存机制。
为什么不使用REST？GraphQL – REST, . REST – GraphQL, REST?
REST URL , . «», id, , id. GraphQL , . , , , GraphQL , .
, REST. Airbnb. , . REST-, REST- . , , GraphQL API, GraphQL, (, ), (., ).
, GraphQL ; , , , . GraphQL – Facebook , -.
, , REST – . , GraphQL. , GraphQL, - .