与 Eve Porcello 一起粉碎播客第 31 集：什么是 GraphQL？

在本集中，我们将讨论 GraphQL。 它是什么，如何解决一些常见的 API 问题？ 我与专家 Eve Porcello 进行了交谈以找出答案。

显示注释

• 夏娃在推特上
• Eve 的公司 Moon Highway
• 向 O'Reilly 学习 GraphQL
• 通过 GraphQL 荒野探索您的道路 - Eve 的 GraphQL 研讨会将于 2021 年初启动

每周更新

• 如何在 Next.js 网站中使用存储在 Sanity 中的 MDX
  由杰森·伦斯托夫撰写
• 使用 Google 的 Dialogflow 构建启用会话 NLP 的聊天机器人
  由 Nwani Victory 撰写
• 用户体验研究中的伦理考虑：培训和审查的必要性
  由维克多·约科撰写
• 让网站更容易交谈
  弗雷德里克·奥布莱恩 (Frederick O'Brien) 撰写
• 当你有一个复杂的解决方案时如何设计一个简单的 UI
  作者：苏珊娜·斯卡卡

成绩单

Drew McLellan：她是一名软件工程师、讲师、作家，以及培训和课程开发公司 Moon Highway 的联合创始人。 她的职业生涯开始于编写技术规范并为 Web 项目创建 UX 设计。 自 2012 年创办 Moon Highway 以来，她为 egghead.io 和 LinkedIn Learning 创建了视频内容，并与人合着了为 O'Reilly 的媒体学习 React 和学习 GraphQL 的书籍。

Drew：她也是会议的常客，曾在 React Rally、GraphQL Summit 和 OSCON 等会议上发表演讲。 所以我们知道她是 GraphQL 方面的专家，但你知道她曾经教过一只北极熊下棋吗？ 我的好朋友们，请欢迎 Eve Porcello。

德鲁：嗨，伊芙，你好吗？

伊芙·波切洛：我太棒了。

Drew：正如我在那里提到的，你在 JavaScript 和 React 等方面非常擅长教育，但我今天想和你谈谈你的其他专业领域之一，GraphQL。 我们中的许多人都会以某种身份听说过 GraphQL，但可能不完全确定它是什么，或者它做了什么，特别是它在 Web 堆栈中解决了什么样的问题。

Drew：那么，如果你愿意，如果我是一名前端开发人员，那么请为我们做好准备，GraphQL 在生态系统中的位置以及它为我执行的功能是什么？

伊芙：是的。 GraphQL 适合前端和后端。 它介于两者之间，为前端开发人员和后端开发人员带来了很多好处。

Eve：如果您是前端开发人员，您可以定义所有前端数据需求。 因此，例如，如果您有一个很大的 React 组件列表，您可以编写一个查询。 这将定义为该页面填充数据所需的所有字段。

Eve：现在有了后端，它真的是自己的了，因为我们可以从很多不同的来源收集很多数据。 所以我们在 REST API、数据库和所有这些不同的地方都有数据。 GraphQL 为我们提供了这个漂亮的小编排层，可以真正理解我们所有数据所在的混乱情况。 所以它对堆栈中的每个人都非常有用。

Drew：所以它基本上是一种基于 API 的技术，不是吗？ 它位于前端和后端之间并提供某种 API，对吗？

Eve：是的，完全正确。 确切地。

Drew：我认为，在过去十年中，API 的黄金标准一直是休息。 因此，如果您有一个客户端应用程序并且您需要使用来自后端的数据填充它，您将构建一个 REST API 端点并查询它。 那么该模型在哪里下降？ 我们什么时候需要 GraphQL 来为我们解决这个问题？

Eve：嗯，GraphQL 真正帮助我们解决的问题，一种黄金问题，黄金解决方案，我猜，GraphQL 提供的是，使用 REST，我们过度获取大量数据。 因此，如果我有 slash 用户或 slash 产品，那将在我每次点击路线时将所有数据返回给我。

Eve：使用 GraphQL，我们可以对我们想要的数据更加挑剔。 因此，如果我只需要来自具有一百个对象的四个字段，我将能够真正查明这些字段，而不必将数据加载到您的设备中，或者我应该说的所有数据加载到您的设备中，因为这是很多额外的工作，尤其是对于您的手机。

Drew：我过去见过并使用过 REST API，它们有一个可选字段，您可以在其中传递您想要返回的数据列表，或者您可以通过额外的东西来增加返回的数据。 所以我想这是在识别这个问题，不是吗？ 也就是说，您并不总是希望每次都返回相同的数据。 那么 GraphQL 是否将允许前端指定后端将返回的数据形式化的方法形式化？

伊芙：是的，没错。 因此，您的查询就变成了您如何询问、如何过滤、如何从任何地方获取任何类型的信息。

Eve：我还认为重要的是要注意我们不必为了真正成功地使用 GraphQL 而拆除所有的 REST API。 我见过很多最成功的 GraphQL 实现，它是围绕 REST API 的包装器。 GraphQL 查询确实为您提供了一种思考所需数据的方法。 然后也许你的一些数据来自我们的用户和产品，例如，一些数据来自 REST，一些来自数据库。

Drew：我想熟悉的场景是，您的网站上可能有一个端点，它返回有关用户的信息以显示标题。 它可能会为您提供他们的用户名和头像。 然后你在每一页上剔除它并填充数据，但是你会在你的应用程序的其他地方发现你需要显示它们的全名。

Drew：所以你将它添加到端点，它开始返回它。 然后你做你的帐户管理部分，你需要像他们的邮寄地址。 所以那个端点也会返回。

Drew：在你知道之前，那个端点正在返回一个很重的有效载荷，后端的成本很高，而且显然要下载很多。

Drew：在每一页都被剔除，只是为了显示一个头像。 所以我想这是随着时间的推移而增长的那种问题，很容易陷入，特别是在大团队中，GraphQL，它就在这个问题之上。 它知道如何解决这个问题，并且它是围绕解决这个问题而设计的。

伊芙：没错。 是的，我认为 GraphQL Schema 的整个想法，我认为真的，它比 GraphQL 的查询语言部分谈论得少。 但我真的觉得 Schema 尤其为我们提供了这个很好的 API 类型系统。

Eve：所以团队中的任何人、经理、前端开发人员、后端开发人员，任何真正处理数据的人都可以聚在一起，围绕我们真正想要在这个 API 上提供的数据进行合并，然后每个人都知道那个来源事实上，他们可以在此基础上构建自己的应用程序部分。

Eve：所以也有一些棘手的 Schema 管理问题。 但就从微服务回到单体应用而言，我们正在这样做，但仍然可以从微服务中获得我们喜欢的所有好处。

Drew：我是否正确理解设置 GraphQL 系统的典型方法是您基本上有一个路由，这是您将所有查询发送到的端点，因此您不必……通常是其中之一最困难的事情是弄清楚要命名什么，以及这个特定查询应该在什么路径上。 是回头客和产品，是砍用户还是砍产品？

Drew：使用 GraphQL，您只有一个端点，您只需将查询发送到该端点，您就会得到适当的响应。

伊芙：没错。 是的。 这是一个单一的端点。 我想，您仍然在处理命名问题，因为您正在命名模式中的所有内容。 但就我而言，我觉得很多公司都在微服务上下了大赌注，每个人都在想，我们有哪些端点？ 他们在哪？ 它们是如何记录的？ 使用 GraphQL，我们有一个地方，一种字典来查找我们想要了解 API 工作原理的任何内容。

Drew：所以，我对其他查询语言非常熟悉，比如 SQL 就是很多 Web 开发人员都知道的查询语言的一个明显例子。 并且其中的查询采用几乎像命令的形式。 这是一个文本字符串，不是吗，从那个，在哪里，随便选择这个。 GraphQL 的查询采用什么格式？

Eve：它仍然是一个技术字符串，但它没有定义该逻辑的来源。 并且很多逻辑被移回服务器。 所以 GraphQL 服务器，GraphQL API 真正负责说，“从它所在的地方获取这些数据，根据这些参数过滤它。”

Eve：但在查询语言中，它是非常面向字段的。 因此，我们只需为要检索的任何内容添加字段。 当然，我们也可以对这些查询进行过滤。 但我认为关于这些信息的来源不太直接。 许多功能都内置在服务器中。

Drew：所以你可以在查询中混合和匹配。 您可以发出一个请求，在一个请求中带回许多不同类型的数据。 那正确吗？

伊芙：是的，完全正确。 因此，您可以针对服务器允许的尽可能多的字段发送查询，并带回各种嵌套数据。 但这就是它的工作原理，我们在字段上连接不同的类型。 所以我想我们会回收我的用户和产品创意，但用户可能有一个产品字段，它返回产品列表。 所有这些也与其他类型相关联。 因此，只要我们希望查询进行深度嵌套，我们就可以。

Drew：这是否意味着在您的 Web 应用程序中为可能发生各种事情的典型视图检索数据，您只需向后端发出一个请求，然后一次性完成所有操作，而无需进行不同的操作查询不同的端点，因为这只是一件事？

伊芙：是的。 这正是整个目标，只是一个查询，定义您想要的每个字段，然后在一个响应中返回它。

Drew：查询是基于 JSON 的，对吗？

Eve：查询本身是一个文本字符串，但它通常返回 JSON 数据。 因此，如果我有这些字段，那么我的 JSON 响应将完全匹配，因此当您发送该查询时，您将得到什么非常清楚，因为数据响应看起来完全一样。

Drew：看起来很多查询几乎都是针对裸对象，比如客户或产品。 有没有办法在后端控制业务逻辑的情况下指定更复杂的查询？ 假设我想获得一个用户的团队列表，但仅限于该用户是团队管理员且团队计划尚未过期的情况，以及我们在日常 Web 应用程序开发中面临的所有这些实际限制。 可以用 GraphQL 实现吗？

伊芙：当然。 所以 GraphQL 真正令人兴奋、强大的地方在于，您可以将大量逻辑移至服务器。 如果您有一个复杂的查询，您想要获取一些非常特定类型的用户，您需要在 Schema 中做的就是说“获取复杂的用户”，然后在服务器上，会有一个函数你可以用任何你想要的语言编写所有的逻辑。 JavaScript 是一种最流行的 GraphQL 实现语言，但您根本不必使用它。 所以 Python、Go、C++，无论你想用什么，你都可以用它来构建一个 GraphQL 服务器。 但是，是的，您可以定义任意复杂的查询。

Drew：我猜这使您能够将大量业务逻辑封装在新类型的对象中。 这公平吗？ 您知道，您设置了一个复杂的用户，然后您无需考虑复杂的用户是什么，但是您可以继续使用该复杂的用户并知道业务逻辑是在其上实现的。 那正确吗？

伊芙：完全正确。 所以我认为这对前端人员来说非常好，因为他们可以开始基于此进行原型设计。 然后后端团队可以去实现这些功能来完成这项工作。 然后对于该类型实际上是什么以及他们是谁，以及“该类型的字段是什么？”有一种共同的理解。 一切都可以由 GraphQL 堆栈中的任何位置处理。 这就是为什么它不是真正的前端或后端技术。 两者兼而有之，两者都不是。

Drew：这听起来像是对 API 以及前端和后端之间的关系进行了形式化，所以每个人都得到了一个可预测的标准化接口。

伊芙：没错。

Drew：我猜在前端和后端由不同团队拥有的组织中，这并不少见，我想这种方法也可以进行更改，比如说，在前端，它可能需要不同的数据，而不需要在后端工作的人进行相应的更改。 如果您需要新数据，您仍然可以获得这个几乎无限可定制的 API，而无需进行任何工作来更改它。

Eve：是的，完全正确。

Drew：那么 GraphQL 服务器是否负责格式化响应，或者您是否需要在服务器端逻辑中这样做？

Eve：所以 GraphQL 服务器定义了两件事。 它定义了存在于服务器上的 Schema 本身，然后定义了解析器函数。 这些函数可以从任何地方获取数据。 因此，如果我有一个使用 GraphQL 包装的 REST API，解析器将从该 API 中获取数据，将数据转换为所需的数据，然后在该函数中将其返回给客户端。 您也可以在该服务器上使用任何类型的数据库功能。 因此，如果您在一堆不同的地方有数据，这是一个非常好的凝聚点，可以将所有数据放入其中并设计所有逻辑，“这些数据来自哪里？ 我们要如何改造它？”

Drew：客户端说，“我想要一个复杂的用户”，服务器在查询中收到它，然后可以说，“好吧，我要查找复杂的用户解析器。” 那正确吗？

Eve：嗯嗯（肯定的）。

Drew：哪个是函数，然后你编写你的逻辑，让你的后端团队，或者在那个函数中编写逻辑的人，做任何必要的事情来返回一个复杂的用户。

伊芙：是的，没错。

Drew：所以这可能是调用其他 API，可能是查询数据库，可能是在缓存中查找内容，或者几乎任何东西。

伊芙：几乎任何东西。 然后，只要函数的返回符合 Schema 的要求，匹配返回的字段、类型，那么一切都会顺利而和谐地工作。

Drew：我猜它默认情况下会在整个 API 中为您提供一致的响应格式。 你不必设计它的样子。 你只会得到一致的结果。

伊芙：是的，没错。

Drew：我认为这真的是一场胜利，因为在大范围的 API 端点之间保持一致性非常困难，尤其是在大型团队中。 不同的人在做不同的事情。 除非你有相当严格的治理，否则它会很快变得非常复杂，不是吗？

伊芙：是的，绝对的。 而且我认为 Schema 就是一个很好的小文档来描述一切。 每当您尝试向其发送查询时，您就可以自动看到该架构中的所有字段，因为您可以发送自省查询，并且有各种不错的工具，例如 GraphQL 和 GraphQL Playground，可用于与 API 数据交互的小工具。

Eve：但是，如果你曾经玩过 Postman，比如 ping 一个 REST API，其中很多，文档实际上并不存在，或者很难找到，或者类似的东西。 GraphQL 确实为您提供了很好的内聚层来描述可能属于该 API 的所有内容。

Drew：实际上，服务器端是如何工作的？ 我的意思是，我猜你需要运行一个 GraphQL 服务作为你的基础设施的一部分，但它采取什么形式呢？ 它是在自己的端口上运行的整个服务器吗？ 或者它就像一个库，你集成到你现有的 Express 或 Apache 中，或者任何带有解析到该服务的路由的库？ 你如何实施它？

Eve：是的，它是一个真正的服务器。 所以最流行的 GraphQL 实现是 Node.js 服务器。 当 GraphQL 作为规范发布时，该团队在 JavaScript 中发布了这个参考实现，这是一种 Node 服务器，为所有其他已经出现的服务器提供指导。 但是，是的，您可以在它们自己的实例上运行这些服务器。 您可以将它们放在 Lambda 上。 所以有 Apollo Server Express，有 Apollo Server Lambda； 您可以使用各种不同类型的实现来实际运行这个东西。

Drew：所以您在服务器拥有的 Schema 概念之前简要提到过。

伊芙：是的。

Drew：这使您能够更严格地描述您的类型，而不仅仅是将名称映射到解析器。 那里涉及更多，是吗？

伊芙：是的。 有完整的语言。 所以我参考了规范，我没有描述它是什么。 GraphQL 本身就是一个描述查询语言和 Schema 定义语言的规范。 所以它有自己的语法。 它有自己定义这些类型的规则。

Eve：当您使用 Schema 定义语言时，您基本上使用了该语言的所有特性来思考，API 中包含哪些类型？ 它也是您定义查询、突变、动词、如操作、创建帐户登录等的地方。 甚至 GraphQL 订阅，这是另一个很酷的东西，你可以在 Schema 中定义的实时 GraphQL。

Eve：所以是的，Schema 真的非常重要。 而且我认为它在我们的整个 Stack 应用程序中为我们提供了这种很好的类型强制，因为一旦你开始偏离这些字段和那些类型，你就会开始看到错误，在这种情况下，这很好，因为你'遵循模式的规则。

Drew：这和 TypeScript 之间有什么交叉吗？ 两者之间是否存在某种协同作用？

伊芙：当然。 因此，如果您是一个经常谈论 GraphQL 的人，有时人们会告诉您它很糟糕，并且当您可以这样做时，他们会公开找到您，并谈论 GraphQL 如何不好。 但是很多时候他们会跳过你从类型中得到的很酷的东西。 因此，就与 TypeScript 的协同作用而言，绝对可以使用 Schema 中的类型为前端应用程序自动生成类型。 所以这是一个巨大的胜利，因为您不仅可以在第一次生成它，从而为您提供与前端应用程序的良好互操作性，而且随着事情的变化，您可以重新生成类型，然后构建以反映这些变化。 所以，是的，我认为随着类型开始成为事实上的规则，这些东西非常适合。

Eve： ……要成为 JavaScript 中的一种事实上的规则，它们很好地结合在一起。

Drew：这似乎是 TypeScript 设计方式的一种持续主题……这不是 TypeScript，抱歉。 GraphQL 的设计有很多关于形式化前端和后端之间的交互。 它作为一种解决方案出现在刚刚创建一致性和形式化之间的解决方案中，到目前为止，对于很多人来说，这是一种相当混乱的休息体验。 在编写客户端应用程序时，我们始终必须牢记的一件事是代码需要接受检查和可能的修改。 并且拥有一个客户端可以请求数据的 API 可能很危险。 现在，如果您可以指定所需的字段，那可能会很危险。 在整个堆栈中，您会处理用户的授权并确保围绕您的数据执行的业务规则？

Eve：你会在服务器上处理所有这些。 因此，这可能以许多不同的方式发生。 您不必使用一次性策略，但您的解析器将处理您的授权。 所以这可能意味着包装一个现有的非 REST API，比如像 Auth0 这样的服务或者你自己构建的东西。 这可能意味着与 OAuth 交互，例如 GitHub、Facebook 或 Google 登录，这些类型的事情涉及与解析器来回传递令牌。 但通常会直接构建到 Schema 中。 所以 Schema 会说，我不知道，我们将创建一个登录突变。 然后我用我的凭据发送该突变，然后在服务器上验证所有这些凭据。 所以客户不用太担心，也许会传递令牌之类的东西。 但其中大部分只是内置在服务器中。

Drew：所以本质上，与我们目前构建休息端点的方式相比，这并没有真正改变。 休息作为一种技术，好吧，它也不真正处理授权，我们在处理它的服务器上有中间件和东西。 GraphQL 也是如此。 你只需处理它。 GraphQL 社区中是否有这样做的约定？ 是否有共同的方法，或者人们选择如何实施它？

伊芙：老实说，到处都是。 我想大多数时候你会看到人们构建到 Schema 中，我的意思是，代表这些类型和授权用户与将这些类型构建到 Schema 本身中的普通用户。 但是您也会看到很多人使用第三方解决方案。 我提到了Auth0。 很多人会将他们的授权转移给更专注于它的公司，特别是小型公司、初创公司等。 但您也会看到更大的公司开始为此创建解决方案。 因此，AWS、Amazon 拥有 AppSync，这是他们的 GraphQL 风格，并且他们将作者卷直接内置到 AppSync 中。 这有点酷，只是能够，我不知道，不必担心所有这些东西，或者至少提供一个处理这些东西的界面。 所以很多这些生态系统工具都有，我认为授权在 GraphQL 中是一个很大的话题。 他们已经看到了某种需要、对身份验证解决方案的需求以及在图表上处理身份验证的标准方法。

Drew：我想几乎没有一个不需要某种授权的实现。 所以，是的，这将是一个相当普遍的要求。 我们都在越来越多地构建组件化的应用程序，特别是当我们使用 React 和 View 以及你所拥有的东西时。 松耦合的原则给我们留下了很多组件，这些组件不一定知道在它们周围的页面上还运行着什么。 这样做是否存在危险，您最终可能会遇到大量组件查询相同的数据并发出多个请求？ 或者它只是您的应用程序中需要解决的架构问题？ 有没有一种成熟的解决方案来处理这个问题？

Eve：嗯，我认为是因为 GraphQL 在大多数情况下，不是 100% 的解决方案，但几乎每个 GraphQL 查询都是通过 HTTP 发送的。 因此，如果您想追踪这些多个请求发生的位置，对于在应用程序中使用休息数据的人来说，这可能是一个相当熟悉的问题。 所以有一些工具，比如 Paulo Client Dev Tools 和 Urkel Dev Tools，供前端开发人员使用，他们会问：“发生了什么事？ 此页面上有哪些查询？” 这使您可以清楚地了解正在发生的事情。 有几种思想流派。 我们是否为页面的所有数据创建了一个巨大的查询？ 或者我们是否创建更小的查询来为应用程序的不同部分加载数据？ 正如您可能想象的那样，它们都有自己的缺点，只是因为如果您有一个很大的查询，您正在等待更多的字段。

Eve：如果您有较小的查询，您需要的数据之间可能会发生冲突。 但我认为，不要太过分了，但我已经在那里了。 因此，GraphQL 规范中出现了一种称为 Deferred Directive 的东西，而 Deferred Directive 将有助于辅助加载内容。 因此，假设您在页面顶部有一些内容，即您要首先加载的超级重要内容。 如果您将其添加到查询中，然后任何后续字段都会获得 deferred 指令。 它只是一个小装饰器，你可以添加到一个字段中，然后它会说，“好吧，先加载重要数据，然后再等待并加载第二个数据。” 它给了你这个，它是一种流数据的外观到你的前端，所以有感知的性能，有交互性。 人们会立即看到数据，而不是等待页面加载每个字段，这可能是个问题。

德鲁：是的。 我想这使您能够构建页面，其中所有内容......我们不喜欢过多地谈论视口，但它是首屏之上的所有内容，您可以优先考虑，加载该加载，然后再进一步加载所有内容下。 所以，我们已经讨论了很多关于查询数据的内容。 API 的主要工作之一是将新的和修改过的数据发送回服务器以进行持久化。 您之前简要提到了突变。 这就是 GraphQL 用于将数据写回服务器的术语？

伊芙：没错。 因此，我们想要对数据进行的任何类型的更改，我们想要写回服务器的任何内容，这些都是突变，这些都就像查询一样，它们被命名为存在于服务器上的操作。 所以你可以想想我们希望我们的用户能够做的所有事情是什么？ 代表那些有突变的人。 然后再次在服务器上，编写使这些东西工作的所有功能。

Drew：这和查询数据一样简单吗？ 调用突变同样容易吗？

伊芙：是的。 它是查询语言的一部分。 它看起来几乎相同。 唯一的区别是，我猜查询包含过滤器。 所以突变在查询本身中采用了看起来像过滤器的东西。 但这些负责实际更改数据。 一封电子邮件和密码可能会随突变一起发送，然后服务器会收集它，然后使用它来授权用户。

Drew：所以，就像以前一样，您正在后端创建一个解析器来处理这个问题并做任何需要做的事情。 写入数据时常见的一种情况是您希望提交更改，然后重新查询以获取它的当前状态。 GraphQL 是否有一个很好的工作流程？

Eve：它有点生活在突变本身中。 因此，很多时候在创建 Schema 时，您会创建变异操作。 我会坚持登录，输入电子邮件和密码。 突变本身返回了一些东西。 所以它可以返回像布尔值这样简单的东西，这很顺利，或者很糟糕，或者它可以返回一个实际的类型。 因此，您经常会看到登录突变之类的突变，也许它会返回一个用户。 因此，一旦用户登录，您就可以获得有关用户的所有信息。或者您可以创建一个自定义对象类型，为您提供该用户以及用户登录的时间，以及返回对象中有关该事务的更多元数据. 再说一次，这完全取决于你自己的设计，但这种模式确实融入了 GraphQL。

Drew：这一切听起来都很棒，但每一个技术选择都需要权衡取舍。 使用 GraphQL 的缺点是什么？ 是否有任何情况下它会是一个非常糟糕的选择？

Eve：我认为 GraphQL 可能会遇到困难的地方是创建一个一对一的地图——

Eve： ……奋斗是创建表格数据的一对一地图。 因此，假设您有，我不知道，认为具有各种不同字段的数据库表，并且，我不知道，特定类型的数千个字段，诸如此类，该类型的数据可以很好地表示使用 GraphQL，但有时当您运行一个流程以在该数据上生成 Schema 时，在 Schema 中，您会遇到与数据库中相同的问题，这可能是超出客户端的数据过多实际上需要。 所以我认为那些地方，它们是潜在的问题。 我和那些根据他们的数据自动生成模式的人交谈过，它变成了一百万行长的模式或类似的东西，只有成千上万行模式代码。 这就是它变得有点棘手的地方，比如它作为人类可读的文档有多大用处？

伊芙：是的。 因此，在您与客户打交道的任何情况下，就对每种不同类型的数据进行建模而言，它非常适合，如果您的数据源太大，它会变得有点棘手。

德鲁：所以这听起来像任何你要仔细策划字段中的响应并更多地手工完成的地方，你可以获得非常强大的结果。 但是，如果您因为刚刚拥有一个庞大的 Schema 而自动生成东西，那么它可能会变得有点笨拙。

伊芙：是的。 我认为人们在倾听我的意见并对此持不同意见，因为也有很好的工具。 但我认为 GraphQL 真正闪耀的地方在于将逻辑抽象到服务器的步骤，让前端开发人员可以自由定义他们的组件或前端数据需求，并真正作为一个团队管理 Schema。

Drew：查询语言中是否有任何内置功能来处理结果的分页，或者是否需要根据需要自定义实现？

伊芙：是的。 分页，您将首先构建到模式中，因此您可以为此定义分页。 社区中出现了很多指导方针。 GitHub GraphQL API 是一个很好的例子，看看你是否是 GraphQL 的新手，我一直在看这个。 他们基本上已经使用 GraphQL 为面向公众的 API v4 重新创建了 API。 所以这是一个很好的地方，可以看看一家真正的大公司是如何大规模使用它的。 很多人都在运行大型 API，但他们不会向所有人公开。 所以分页非常好地内置在该 API 中，您可以返回（我不知道）您曾经创建的前 50 个存储库，或者您也可以使用基于游标的分页来根据数据中的想法返回记录。 因此，基于光标的分页和位置分页，例如第一条记录，最后一条记录，这通常是人们处理它的方式，但有很多技术。

Drew：在使用 GraphQL 时我们应该知道哪些大问题？ 假设我要为我的组织部署新的 GraphQL 安装，我们将使用 GraphQL 构建所有新的 API 端点。 我应该知道什么？ 灌木丛里有什么东西吗？

Eve：潜伏在灌木丛中，总是带着技术，对吧？ 我认为 GraphQL 中没有内置但可以毫不费力地实现的一件事是 API 安全性。 例如，你提到如果我有一个巨大的查询，我们在授权的情况下讨论了这个，但是打开一个 API 也很可怕，有人可以发送一个巨大的嵌套查询，朋友的朋友，朋友的朋友，朋友的朋友, 顺着链条向下。 然后你基本上允许人们用这些巨大的查询对你进行 DDoS 攻击。 So there's things that you can set up on the server to limit query depth and query complexity. You can put queries on a safe list. So maybe your front ends, you know what they all are and it's not a public API. So you only want to let certain queries come over the wire to you. So I would say before rolling that out, that is definitely a possible gotcha with the GraphQL.

Drew: You do a lot of instruction and training around GraphQL, and you've co-written the O'Reilly 'animal' book with Alex Banks called Learning GraphQL. But you've got something new that you're launching early in 2021, is that right?

Eve: That's right. So I have been collaborating with egghead.io to create a full stack GraphQL video course. We're going to build an API and front end for a summer camp, so everything is summer camp themed. And yeah, we're just going to get into how to work with Apollo server, Apollo client. We will talk about scaling GraphQL APIs with Apollo Federation. We'll talk about authorization strategies and all sorts of different things. So it's just kind of collecting the things that I've learned from teaching over the past, I don't know, three or four years GraphQL and putting it into one spot.

Drew: So it's a video course that… Is it all just self-directed, you can just work your way through at your own pace?

Eve: Yeah, exactly. So it's a big hefty course so you can work through it at your own pace. 绝对地。

Drew: Oh, that sounds really good. And it's graphqlworkshop.com, is that right?

Eve: Graphqlworkshop.com, exactly.

Drew: And I'm looking forward to seeing that released because I think that's something that I might need. So I've been learning all about GraphQL. What have you been learning about lately?

Eve: I've also been looking into Rust lately. So I've been building a lot of Rust Hello Worlds, and figuring out what that is. I don't know if I know what that is yet, but I have been having fun tinkering around with it.

Drew: If you dear listener, would like to hear more from Eve, you can find her on Twitter where she's @eveporcello, and you can find out about her work at moonhighway.com. Her GraphQL workshop, discover your path through the GraphQL wilderness, is coming out early in 2021 and can be found at graphqlworkshop.com. Thanks for joining us today, Eve. 你有什么离别词吗？

Eve: Parting words, have fun with GraphQL, take the plunge, you'll enjoy it, and thanks so much for having me. 我很感激。