让GraphQL在WordPress中发挥作用

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

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

直到最近，WPGraphQL是WordPress的唯一GraphQL服务器。但现在又有了一个这样的插件。WordPress的GraphQL API，是由我撰写的。

这两个插件的目的是一样的：为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框架的讨论区问过这个问题，并被告知可能会被考虑。我也在WebDevStudios的Next.js WordPress Starter讨论区问过，但可惜的是，我的问题立即被删除了，没有任何回应。(这并不令人鼓舞，不是吗？)

所以，在目前和可预见的将来，WPGraphQL就是这样的。

如果使用其中一个（或两个）。使用Frontity

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

Frontity管理应用程序的状态，不泄露数据的获取方式。尽管它默认是基于REST的，但你也可以通过实现相应的源插件，通过GraphQL为它提供动力。

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

结论。无论是WPGraphQL还是GraphQL API，在与Frontity合作方面都没有提供任何优势，而且它们都需要一些初始努力来插入它们。

使用WPGraphQL，如果。创建一个静态网站

在前两节中，结论是一样的：使用WPGraphQL。但我对这个结论的反应是不同的。对于Gatsby，我没有什么遗憾，而对于Next.js，我觉得必须要做点什么。

这是为什么呢？

不同的是，Gatsby是纯粹的静态网站生成器，而Next.js可以同时为静态和实时网站提供动力。

我提到，WPGraphQL对Gatsby来说已经足够好了。这个说法其实可以扩大。WPGraphQL对于任何静态网站生成器来说已经足够好了。一旦静态网站生成器从WordPress网站获得数据，它就基本与WordPress解决了。

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

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

使用GraphQL API如果。在一个实时（即非静态）网站中使用GraphQL

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

例如，假设我们使用Next.js框架之一建立了一个简单的静态博客，我们想让用户为博客文章添加评论。这个任务应该如何处理？

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

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

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

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

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

对于一个纯粹的静态网站，WordPress网站可以保持私密性（甚至可能生活在开发者的笔记本电脑上），所以它是安全的。而且用户不会等待来自服务器的响应，所以速度不一定是最重要的。

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

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

WPGraphQL确实实施了安全措施，比如默认情况下禁用自省。但WordPress的GraphQL API走得更远，它默认禁用了单一的端点（还有其他一些措施）。这是可能的，因为WordPress的GraphQL API提供了原生的持久化查询。

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

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

使用GraphQL API，如果。为不同的用户或应用程序暴露不同的数据

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

根据上下文，我们可能需要我们的GraphQL APIs来暴露不同的数据，比如说。

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

为了暴露不同的数据，我们需要提供不同版本的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 指令调用谷歌翻译API，将许多帖子的标题和摘要从英语翻译成西班牙语。在一次调用中，所有文章的所有字段都被一起翻译。

WordPress的GraphQL API是这个用例的一个自然选择。

注意：事实上，WordPress的GraphQL API所基于的引擎，GraphQL by PoP，是专门为提供高级数据处理能力而设计的。这是它的一个显著特点。关于它能实现的一个极端的例子，请看 "按用户发送本地化的通讯"的指南。

使用WPGraphQL，如果。你想要一个支持社区

Jason Bahl在召集WPGraphQL的社区方面做得非常好。因此，如果你需要排除GraphQL API的故障，你很可能会找到可以帮助你的人。

就我而言，我仍然在努力创建一个围绕WordPress的GraphQL API的用户社区，当然，它远没有达到WPGraphQL的水平。

使用GraphQL API，如果。你喜欢创新

我把WordPress的GraphQL API称为一个 "前瞻性 "的GraphQL服务器。原因是我经常浏览GraphQL规范的请求列表，并提前实现其中的一些请求（特别是那些我觉得有些亲和力的或我可以用很少的努力来支持的）。

到今天为止，WordPress的GraphQL API支持几个创新的功能（如多个查询的执行和模式命名间隔），作为opt-in提供，并有计划提供更多的功能。

使用WPGraphQL，如果。您需要一个完整的模式

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

• 帖子和页面。
• 自定义帖子类型。
• 类别和标签。
• 自定义分类法。
• 媒体。
• 菜单。
• 设置。
• 用户。
• 评论。
• 插件。
• 主题。
• 小工具。

WordPress的GraphQL API在每个新版本中都会逐步映射出数据模型。到今天为止，这个列表包括。

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

因此，如果你需要从一个插件、主题或小工具中获取数据，目前只有WPGraphQL可以做到这一点。

使用WPGraphQL，如果。您需要扩展

WPGraphQL为许多插件提供扩展，包括高级自定义字段、WooCommerce、Yoast、Gravity Forms。

WordPress的GraphQL API为Events Manager提供了一个扩展，在该插件1.0版本发布后，它将不断增加更多的扩展。

如果使用这两种方式。为WordPress编辑器创建区块

WPGraphQL和GraphQL API for WordPress目前都在努力将GraphQL与Gutenberg整合。

Jason Bahl描述了三种可以进行这种整合的方法。然而，由于所有这些方法都有问题，他主张为WordPress引入一个服务器端的注册表，以便能够识别GraphQL模式的不同Gutenberg块。

WordPress的GraphQL API也有一个与Gutenberg整合的方法，基于 "一次创建，到处发布 "的策略。它从存储的内容中提取块数据，它使用一个单一的Block 类型来代表所有的块。这种方法可以避免对拟议的服务器端注册表的需求。

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

对于WordPress的GraphQL API来说，解决方案将完全取决于它自己，而且它确实已经是一项正在进行的工作。

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

使用GraphQL API 如果。通过插件分发区块

我悟出了一个道理。似乎没有多少插件（如果有的话）在WordPress中使用GraphQL。

不要误会我的意思。WPGraphQL已经超过了10,000次安装。但我相信，那些安装大多是为了支持Gatsby（为了运行Gatsby）或支持Next.js（为了运行其中一个无头框架）。

同样地，WPGraphQL也有很多扩展，正如我前面所描述的。但这些扩展仅仅是：扩展。它们不是独立的插件。

例如，WPGraphQL for WooCommerce扩展依赖于WPGraphQL和WooCommerce插件。如果它们中的任何一个没有安装，那么这个扩展将无法工作，这没有问题。但WooCommerce没有选择依靠WPGraphQL来工作；因此，WooCommerce插件中不会有GraphQL。

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

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

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

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

目前正在开发的全站编辑是基于REST的。那么，在Gutenberg的第四阶段将解决的下一个主要功能--多语言块呢？如果不是这样，那会是哪个功能呢？)

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

几天前，我有了另一个认识。从GraphQL API for WordPress的代码库中，我可以制作一个较小的版本，只包含GraphQL引擎，而没有其他东西（没有用户界面，没有自定义端点，没有HTTP缓存，没有访问控制，没有任何东西）。这个版本可以作为Composer的依赖项发布，这样插件就可以安装它来驱动他们自己的块。

这种方法的关键是，这个组件必须对插件有特定的用途，不能与其他任何人共享。否则，两个同时引用这个组件的插件可能会以这样的方式修改模式，使它们互相覆盖。

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

这意味着它将对任何事件的组合起作用。

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

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

这个组件将被称为私有GraphQL API，应该在几周内准备好。我已经开始工作了）。

因此，我的建议是，如果你想在你的插件中使用GraphQL来驱动Gutenberg块，请等待几周，然后看看GraphQL API for WordPress的小兄弟，Private GraphQL API。

总结

尽管我在游戏中确实有皮肤，但我认为我已经设法写了一篇大部分是客观的文章。

我已经诚实地说明了为什么以及何时你需要使用WPGraphQL。同样地，我也诚实地解释了为什么WordPress的GraphQL API似乎比WPGraphQL在一些使用情况下更好。

在一般情况下，我们可以总结如下。

• 用WPGraphQL去静态化，或者用WordPress的GraphQL API去生活。
• 用WPGraphQL玩得安全，或者投资于WordPress的GraphQL API（为了一个潜在的值得的回报）。

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

有用的链接

• WPGraphQL：文档、下载页面、代码库
• WordPress的GraphQL API：文档、下载页面、代码库
• "The Gatsby WordPress Integration Workshop"
  YouTube视频，有WPGraphQL的演示。
• "WordPress的GraphQL API介绍"
  YouTube视频，演示WordPress的GraphQL API