让 GraphQL 在 WordPress 中工作

无头 WordPress 最近似乎很流行，在过去几周内发生了许多新的发展。 活动激增的原因之一是 WPGraphQL 1.0 版的发布，这是 WordPress 的 GraphQL 服务器。

WPGraphQL 提供了 GraphQL API：一种从 WordPress 网站获取数据并将数据发布到 WordPress 网站的方法。 它使我们能够将通过 WordPress 完成的内容管理体验与呈现网站分离，为此我们可以使用我们选择的框架库（React、Vue.js、Gatsby、Next.js 或任何其他）。

直到最近，WPGraphQL 还是 WordPress 唯一的 GraphQL 服务器。 但是现在可以使用另一个这样的插件：由我编写的 GraphQL API for WordPress。

这两个插件具有相同的目的：为 WordPress 网站提供 GraphQL API。 您可能想知道：既然已经有了 WPGraphQL，为什么还要另一个插件？ 这两个插件做同样的事情吗？ 还是它们适用于不同的情况？

让我先说一下：WPGraphQL 效果很好。 我没有构建我的插件，因为它有任何问题。

我为 WordPress 构建了 GraphQL API，因为我一直在研究一个能够高效检索数据的引擎，而这恰好非常适合 GraphQL。 所以，然后我对自己说，“为什么不呢？”，然后我建造了它。 （还有其他几个原因。）

这两个插件具有不同的架构，赋予它们不同的特性，这使得使用一个插件或另一个插件更容易实现特定任务。

在本文中，我将从我自己的观点但尽可能客观地描述，什么时候 WPGraphQL 是要走的路，什么时候 GraphQL API for WordPress 是一个更好的选择。

使用 WPGraphQL 如果：使用 Gatsby

如果您正在使用 Gatsby 构建网站，那么只有一个选择：WPGraphQL。

原因是只有 WPGraphQL 有 WordPress 的 Gatsby 源插件。 此外，WPGraphQL 的创建者 Jason Bahl 直到最近才受雇于 Gatsby，因此我们可以完全相信这个插件会满足 Gatsby 的需求。

Gatsby 从 WordPress 网站接收所有数据，从那时起，应用程序的逻辑将完全在 Gatsby 这边，而不是在 WordPress 那边。 因此，对 WPGraphQL 的任何添加（例如@stream或@defer指令的潜在添加）不会产生很大的不同。

WPGraphQL 已经和 Gatsby 需要的一样好。

在以下情况下使用 WPGraphQL：使用新的无头框架之一

正如我所提到的，最近在 WordPress 无头空间中出现了一系列关于几个新框架和入门项目的活动，它们都基于 Next.js：

• Colby Fayock 创建了 Next.js WordPress Starter。
• WebDevStudios 推出了自己的 Next.js WordPress Starter。
• WP Engine 创建了 Headless WordPress 框架，该框架为其服务提供支持，以托管和部署无头 WordPress 网站。

如果您需要使用这些新的无头框架中的任何一个，那么您将需要使用 WPGraphQL，因为它们都构建在这个插件之上。

这有点不幸：我真的很喜欢 GraphQL API for WordPress 也能够为它们提供动力。 但要做到这一点，这些框架需要通过接口与 GraphQL 一起操作，以便我们可以交换 GraphQL 服务器。

我有点希望这些框架中的任何一个都能将这样的接口落实到位。 我在 Headless WordPress Framework 讨论板中询问了它，并被告知可能会考虑它。 我也在 WebDevStudios 的 Next.js WordPress Starter 讨论区中提问，但是很遗憾，我的问题立即被删除，没有任何回应。 （不鼓励，是吗？）

所以现在和可预见的未来都是 WPGraphQL。

如果：使用 Frontity

Frontity 是 WordPress 的 React 框架。 它使您能够构建一个基于 React 的应用程序，该应用程序通过 WordPress 在后端进行管理。 甚至使用 WordPress 编辑器创建博客文章也是开箱即用的。

Frontity 管理应用程序的状态，而不会泄露数据的获取方式。 即使它默认基于 REST，您也可以通过 GraphQL 通过实现相应的源插件来支持它。

这就是 Frontity 的聪明之处：源插件是与数据提供者通信的接口。 目前，唯一可用的源插件是用于 WordPress REST API 的插件。 但是任何人都可以为 WordPress 的 WPGraphQL 或 GraphQL API 实现源插件。 （这是我希望基于 Next.js 的框架复制的方法。）

结论：WPGraphQL 和 GraphQL API 在使用 Frontity 方面都没有提供任何优势，而且它们都需要一些初步的努力来插入它们。

在以下情况下使用 WPGraphQL：创建静态站点

在前两节中，结论是相同的：使用 WPGraphQL。 但我对这个结论的反应是不同的：虽然使用 Gatsby 我并不后悔，但使用 Next.js 我觉得有必要为此做点什么。

这是为什么？

不同之处在于，虽然 Gatsby 是纯粹的静态网站生成器，但 Next.js 可以为静态网站和实时网站提供支持。

我提到 WPGraphQL 对于 Gatsby 来说已经足够好了。 这句话实际上可以扩展： WPGraphQL 对于任何静态站点生成器来说已经足够好了。 静态站点生成器从 WordPress 网站获取数据后，几乎可以使用 WordPress 解决。

即使 GraphQL API for WordPress 提供了额外的功能，它也很可能不会对静态站点生成器产生影响。

因此，因为 WPGraphQL 已经足够好，并且它已经完全映射了 GraphQL 模式（这仍然是 GraphQL API for WordPress 的一项工作），所以 WPGraphQL 是现在和可预见的未来最合适的选择。

在以下情况下使用 GraphQL API：在实时（即非静态）网站中使用 GraphQL

现在，如果我们希望 GraphQL 从实时网站获取数据，例如在为移动应用程序提供动力或在网站上绘制实时数据（例如，显示分析）或结合静态和实时方法时，上述情况会发生变化在同一个网站上。

例如，假设我们使用其中一个 Next.js 框架构建了一个简单的静态博客，并且我们希望允许用户向博客文章添加评论。 这个任务应该如何处理？

我们有两种选择：静态和实时（或动态）。 如果我们选择静态，那么评论将与网站的其余部分一起呈现。 然后，每当添加评论时，我们必须触发一个 webhook 来重新生成和重新部署网站。

这种方法有一些不便之处。 重新生成和重新部署过程可能需要几分钟，在此期间新评论将不可用。 此外，如果网站每天收到很多评论，静态方法将需要更多的服务器处理时间，这可能会变得昂贵（一些托管公司根据服务器时间收费）。

在这种情况下，静态渲染网站而不使用评论是有意义的，然后从实时站点中检索评论并在客户端中动态渲染它们。

为此，建议使用 Next.js 而不是 Gatsby。 它可以更好地处理静态和实时方法，包括为不同能力的用户支持不同的输出。

回到 GraphQL 讨论：为什么我在处理实时数据时推荐 GraphQL API for WordPress？ 我这样做是因为 GraphQL 服务器可以对应用程序产生直接影响，主要是在速度和安全性方面。

对于纯静态网站，WordPress 网站可以保密（它甚至可能存在于开发人员的笔记本电脑上），因此它是安全的。 并且用户不会等待来自服务器的响应，因此速度不一定是至关重要的。

但是，对于实时站点，GraphQL API 将公开，因此数据安全成为一个问题。 我们必须确保没有恶意行为者可以访问它。 此外，用户将等待响应，因此速度成为一个关键的考虑因素。

在这方面， WordPress 的 GraphQL API 比 WPGraphQL 有一些优势。

WPGraphQL 确实实现了安全措施，例如默认禁用自省。 但是 WordPress 的 GraphQL API 更进一步，默认情况下禁用单个端点（以及其他一些措施）。 这是可能的，因为 GraphQL API for WordPress 原生提供持久化查询。

至于速度，持久化查询也使 API 更快，因为响应可以通过 HTTP 缓存在多个层上进行缓存，包括客户端、内容交付网络和服务器。

这些原因使 GraphQL API for WordPress 更适合处理实时网站。

在以下情况下使用 GraphQL API：为不同的用户或应用程序公开不同的数据

WordPress 是一个多功能的内容管理系统，能够管理多个应用程序的内容并可供不同类型的用户访问。

根据上下文，我们可能需要我们的 GraphQL API 来公开不同的数据，例如：

• 将某些数据暴露给付费用户，但不暴露给非付费用户，
• 将某些数据暴露给移动应用程序而不是网站。

为了暴露不同的数据，我们需要提供不同版本的 GraphQL 模式。

WPGraphQL 允许我们修改模式（例如，我们可以删除已注册的字段）。 但是这个过程并不简单：必须对模式修改进行编码，并且不容易理解谁在访问什么以及在哪里访问（例如，所有模式在单个端点/graphql下仍然可用）。

相比之下，用于 WordPress 的 GraphQL API 原生支持这种用例：它提供了自定义端点，可以针对不同的上下文公开不同的数据，例如：

• /graphql/mobile-app和/graphql/website ,
• /graphql/pro-users和/graphql/regular-users 。

每个自定义端点都通过访问控制列表进行配置，以逐个字段提供精细的用户访问，以及公共和私有 API 模式来确定架构的元数据是对所有人可用还是仅对授权用户可用。

这些功能直接与 WordPress 编辑器（即 Gutenberg）集成。 因此，创建不同的模式是在视觉上完成的，类似于创建博客文章。 这意味着每个人都可以生成自定义 GraphQL 模式，而不仅仅是开发人员。

我相信，用于 WordPress 的 GraphQL API 为这个用例提供了一个自然的解决方案。

在以下情况下使用 GraphQL API：与外部服务交互

GraphQL 不仅仅是一个用于获取和发布数据的 API。 同样重要（尽管经常被忽视），它还可以处理和更改数据——例如，通过将其提供给某些外部服务，例如将文本发送到第三方 API 以修复语法错误或将图像上传到内容交付网络。

现在，GraphQL 与外部服务通信的最佳方式是什么？ 在我看来，这最好通过指令来完成，在创建或检索数据时应用（与 WordPress 过滤器的操作方式不同）。

我不知道 WPGraphQL 与外部服务的交互有多好，因为它的文档没有提到它，并且代码库没有提供任何指令的示例或文档如何创建一个。

相比之下，用于 WordPress 的 GraphQL API对指令有强大的支持。 查询中的每个指令总共只执行一次（而不是每个字段和/或对象一次）。 此功能可实现与外部 API 的高效通信，并将 GraphQL API 集成到服务云中。

例如，此查询演示了通过@translate指令调用 Google Translate API，将许多帖子的标题和摘录从英语翻译成西班牙语。 所有帖子的所有字段都在一次调用中一起翻译。

用于 WordPress 的 GraphQL API 是此用例的自然选择。

注意：事实上，GraphQL API for WordPress 所基于的引擎，GraphQL by PoP，是专门为提供高级数据操作能力而设计的。 这是其鲜明的特点之一。 有关它可以实现什么的极端示例，请查看“按用户发送本地化时事通讯”指南。

在以下情况下使用 WPGraphQL：您想要一个支持社区

Jason Bahl 在围绕 WPGraphQL 凝聚社区方面做得非常出色。 因此，如果您需要对 GraphQL API 进行故障排除，您可能会找到可以帮助您的人。

就我而言，我仍在努力围绕 GraphQL API for WordPress 创建一个用户社区，而且它肯定与 WPGraphQL 相去甚远。

如果您喜欢创新，请使用 GraphQL API

我将 GraphQL API for WordPress 称为“前瞻性”GraphQL 服务器。 原因是我经常浏览 GraphQL 规范的请求列表，并提前实现其中的一些（尤其是那些我觉得有些亲近或我可以毫不费力地支持的请求）。

截至今天，用于 WordPress 的 GraphQL API 支持多种创新功能（例如多查询执行和模式命名空间），作为可选功能提供，并且还有更多的计划。

在以下情况下使用 WPGraphQL：您需要完整的架构

WPGraphQL 已经完全映射了 WordPress 数据模型，包括：

• 帖子和页面，
• 自定义帖子类型，
• 类别和标签，
• 自定义分类法，
• 媒体，
• 菜单，
• 设置，
• 用户，
• 注释，
• 插件，
• 主题，
• 小部件。

用于 WordPress 的 GraphQL API 正在逐步将数据模型映射到每个新版本。 截至今天，该名单包括：

• 帖子和页面，
• 自定义帖子类型，
• 类别和标签，
• 自定义分类法，
• 媒体，
• 菜单，
• 设置，
• 用户，
• 注释。

因此，如果您需要从插件、主题或小部件中获取数据，目前只有 WPGraphQL 可以完成这项工作。

在以下情况下使用 WPGraphQL：您需要扩展

WPGraphQL 为许多插件提供扩展，包括 Advanced Custom Fields、WooCommerce、Yoast、Gravity Forms。

GraphQL API for WordPress 为事件管理器提供了一个扩展，它会在插件 1.0 版发布后继续添加更多。

使用 If：为 WordPress 编辑器创建块

WordPress 的 WPGraphQL 和 GraphQL API 目前都在致力于将 GraphQL 与 Gutenberg 集成。

Jason Bahl 描述了可以进行这种集成的三种方法。 然而，因为它们都有问题，他主张在 WordPress 中引入服务器端注册表，以便识别 GraphQL 模式的不同 Gutenberg 块。

用于 WordPress 的 GraphQL API 还具有与 Gutenberg 集成的方法，基于“创建一次，随处发布”策略。 它从存储的内容中提取块数据，并使用单个Block类型来表示所有块。 这种方法可以避免对建议的服务器端注册表的需要。

WPGraphQL 的解决方案可以被认为是暂定的，因为它将取决于社区接受使用服务器端注册表，我们不知道是否或何时会发生这种情况。

对于 GraphQL API for WordPress，解决方案将完全依赖于它自己，而且它确实已经在进行中。

因为它更有可能很快产生一个可行的解决方案，所以我倾向于推荐GraphQL API for WordPress 。 但是，让我们等待解决方案完全实施（几周后，根据计划）以确保它按预期工作，然后我将更新我的建议。

在以下情况下使用 GraphQL API：通过插件分发块

我意识到：似乎没有多少插件（如果有的话）在 WordPress 中使用 GraphQL。

不要误会我的意思：WPGraphQL 的安装量已超过 10,000。 但我相信这些主要是为 Gatsby 提供动力（以运行 Gatsby）或为 Next.js 提供动力（以运行无头框架之一）的安装。

同样，正如我之前描述的，WPGraphQL 有许多扩展。 但这些扩展只是：扩展。 它们不是独立的插件。

例如，WooCommerce 扩展的 WPGraphQL 依赖于 WPGraphQL 和 WooCommerce 插件。 如果其中任何一个未安装，则扩展将无法工作，这没关系。 但是 WooCommerce 没有选择依赖 WPGraphQL 来工作； 因此，WooCommerce 插件中不会有 GraphQL。

我的理解是，没有任何插件使用 GraphQL 来运行 WordPress 本身的功能，或者特别是为其 Gutenberg 块提供动力。

原因很简单：WordPress 的 WPGraphQL 和 GraphQL API 都不是 WordPress 核心的一部分。 因此，不可能像插件依赖 WordPress 的 REST API 那样依赖 GraphQL。 因此，实现 Gutenberg 块的插件只能使用 REST 来获取其块的数据，而不是 GraphQL。

看起来，解决方案是等待将 GraphQL 解决方案（很可能是 WPGraphQL）添加到 WordPress 核心。 但谁知道这需要多长时间？ 六个月？ 一年？ 两年？ 更长？

我们知道 WPGraphQL 正在考虑用于 WordPress 的核心，因为 Matt Mullenweg 已经暗示过。 但是在此之前必须发生很多事情：将最低 PHP 版本提升到 7.1（WPGraphQL 和 GraphQL API for WordPress 都需要），以及对 GraphQL 支持的功能有清晰的解耦、理解和路线图。

（目前正在开发的全站点编辑基于 REST。那么在 Gutenberg 的第 4 阶段中要解决的下一个主要功能，多语言块呢？如果不是，那么它将是哪个功能？）

在解释了问题之后，让我们考虑一个潜在的解决方案——一个不需要等待的解决方案！

几天前，我有了另一个认识：从 GraphQL API for WordPress 的代码库，我可以生成一个更小的版本，只包含 GraphQL 引擎，没有其他内容（没有 UI，没有自定义端点，没有 HTTP 缓存，没有访问控制，没什么）。 此版本可以作为 Composer 依赖项分发，以便插件可以安装它来为自己的块提供动力。

这种方法的关键是该组件必须对插件有特定用途，而不是与其他任何人共享。 否则，两个引用此组件的插件可能会修改架构，从而使它们相互覆盖。

幸运的是，我最近解决了 WordPress 的 GraphQL API 范围问题。 所以，我知道我能够完全确定它的范围，生成一个不会与网站上任何其他代码冲突的版本。

这意味着它将适用于任何事件组合：

• 如果包含该组件的插件是唯一使用它的插件；
• 如果 GraphQL API for WordPress 也安装在同一网站上；
• 如果网站上安装了另一个也嵌入该组件的插件；
• 如果嵌入该组件的两个插件引用该组件的相同版本或不同版本。

在每种情况下，插件都有自己独立的、私有的 GraphQL 引擎，它可以完全依靠它来为其 Gutenberg 块提供动力（我们不必担心任何冲突）。

这个被称为Private GraphQL API的组件应该会在几周内准备好。 （我已经开始研究它了。）

因此，我的建议是，如果您想在插件中使用 GraphQL 为 Gutenberg 块提供动力，请等待几周，然后查看 GraphQL API 用于 WordPress 的弟弟，即 Private GraphQL API。

结论

尽管我确实在游戏中有所作为，但我认为我已经设法写了一篇主要是客观的文章。

我一直诚实地说明为什么以及何时需要使用 WPGraphQL。 同样，我一直诚实地解释为什么 WordPress 的 GraphQL API 在几个用例中似乎比 WPGraphQL 更好。

一般而言，我们可以总结如下：

• 使用 WPGraphQL 实现静态化，或使用 GraphQL API for WordPress 上线。
• 使用 WPGraphQL 确保安全，或投资 GraphQL API for WordPress（以获得潜在的有价值的回报）。

最后一点，我希望 Next.js 框架被重新设计以遵循 Frontity 使用的相同方法：他们可以访问接口来获取他们需要的数据，而不是使用某些特定解决方案的直接实现（当前是 WPGraphQL）。 如果发生这种情况，开发人员可以根据他们的需要——从项目到项目——选择使用哪个底层服务器（无论是 WPGraphQL、WordPress 的 GraphQL API 还是未来引入的其他解决方案）。

有用的链接

• WPGraphQL：文档、下载页面、代码存储库
• 用于 WordPress 的 GraphQL API：文档、下载页面、代码存储库
• “盖茨比 WordPress 集成研讨会”
  带有 WPGraphQL 演示的 YouTube 视频
• “WordPress 的 GraphQL API 简介”
  带有 GraphQL API for WordPress 演示的 YouTube 视频