按此：WPGraphQL 和 Faust.js

欢迎来到 Press This，WMR 的 WordPress 社区播客。 每集都有来自社区各地的嘉宾和 WordPress 开发人员面临的最大问题的讨论。 以下是原始录音的转录。

由 RedCircle 提供技术支持

Doc Pop ：您正在收听 Press This，WMR 上的 WordPress 社区播客。 每周我们都会聚焦 WordPress 社区的成员。 我是你的主人，Doc Pop。 我通过我在 WP Engine 的角色以及我在 TorqueMag.Io 上的贡献来支持 WordPress 社区，在那里我可以做播客、画卡通和教程视频。 检查出。

您可以在 Red Circle、iTunes、Spotify 上订阅 Press This，也可以直接从 wmr.fm 下载剧集。

在 Press This 的这一集中，我们谈论的是 Headless WordPress、GraphQL 和 Faust.js。 如何将这些工具一起使用以及与 Headless WordPress 相关的成本类型。 我们将尝试深入研究这个问题，今天有两位伟大的客人加入我的行列，我有 Jason Bahl，他是位于科罗拉多州丹佛市的 WP Engine 的首席软件工程师，他在那里维护 WPGraphQL . 我们有 Chris Weigman，他是 Faust.js 的工程经理。 我通常喜欢在开始这些节目时向客人询问他们的 WordPress 起源故事，但我想我会在这里稍微改变一下。

Jason，你能告诉我们什么是 WPgraphQL 以及它的 wordPress 起源故事吗？

Jason Bahl：哦，是的，WPGraphQL 是一个免费的开源 WordPress 插件，它将 GraphQL API 带到您的 WordPress 站点，而 GraphQL 是图形查询语言。 因此，它允许开发人员使用图形查询语言从 WordPress 中获取内容。

这个插件起源于几年前我在一家报纸工作，我们做了很多内容联合。 我们有一个大约由 54 个站点组成的网络，遍布美国各地，我们需要将内容从一侧移动到另一侧。 你知道，当一篇新闻报道发表时，不同的报纸可以订阅其他报纸的内容。

因此，当各种事件发生时，我们需要在该网络中移动数据，我们使用 WordPress REST API 来完成大量数据移动。 并且在技术上遇到了一些问题，比如技术上的实际性能，还有开发人员的体验。 我发现了 GraphQL，这是真正的图形查询语言，它于 2015 年由 Facebook 开源。

所以我找到了这项技术，做了一些原型设计，将它推销给我的同事，然后我们将我们的联系人联合组织从 REST 迁移到 GraphQL。 然后我继续将这个项目作为一个社区项目进行工作，我知道 JavaScript 框架正在成为热门事物，并且这可能是使用 GraphQL 的主要用例，就像服务器到服务器通信不是主要用例一样。 它解决了我们的需求，但我看到了更大的愿景，所以我一直致力于将其作为社区的开源项目。

DP：嗯，很酷。 克里斯，你能告诉我们一个类似的故事吗，关于浮士德是什么以及它是如何产生的？

Chris Weigman： Sure Faust，最近，实际上是本周，正式向公众发布，重新发布到使用 GraphQL 构建 Headless WordPress 网站的公共框架。 2020 年就开始开发了，算是 WP Engine 的一个非官方项目，这是第三个主要支点。

他们把它作为 DevRel 的扩展开始，开始使它更正式一点，并转向一种叫做 GQty 的东西和一种非常 JavaScript，开发人员第一的心态。 然后当我在去年 12 月 1 日接管团队时，我们意识到那不是我们的目标市场。

我们应该一直在为 WordPress 开发人员开发。 所以我们又开始重建它，最近才终于能够重新发布。

DP：杰森，你最近在推特上说你已经在 Faust.js 上推出了新的 wpgraphql.com。 以前的站点，我相信是无头的 WordPress。 你能告诉我们你所做的这个改变吗？你知道，你说的是什么改进？

JB：是的。 所以 wpgraphql.com，它多年来一直是一个无头网站。 所以我正在使用多个数据源。 所以我有很多内容在 WordPress 中，像博客文章都在 WordPress 中。

一些文档也存在于 WordPress 中。 然后一些文档存在于 GitHub 存储库的降价文件中。 在我使用 Gatsby 的最长时间里，大概三年，我一直在使用 Gatsby，它是一个 JavaScript 框架，其核心具有数据层，您可以在其中从多个来源提取数据。

所以我正在使用它，它会从 GitHub 中提取数据，也使用 WPGraphQL 从 WordPress 中提取数据，并允许我使用该数据来构建我的模板。 所以我用了几年。 我想摆脱的数据层有很多痛点。

所以我想使用 Faust 构建的 Next。 它是另一个 JavaScript 框架，但我猜有很多遗漏的部分。 接下来，许多 JavaScript 框架都认为您的前端框架应该定义所有路由，对吗？ 但如果您使用的是 CMS，则您的 CMS 会定义路由。

所以有很多技术问题让这些东西发挥得很好，就像你的前端对某事有意见而你的后端有不同的意见。 所以就像我试图解决的一个问题是让我的前端识别一个特定的 URL 是一个特定类型的东西，然后呈现一个代表那个东西的模板。

就像博客文章与文档或用户档案或其他任何东西具有不同的模板一样。 所以我希望我的前端能够将 URL 发送到 CMS，取回数据，但了解要返回的模板。 在 WordPress 中，它称为模板层次结构。 所以当 Faust 团队能够解决这个问题时，我想，哎呀，我要转向 Faust。

所以，是的，我能够采用核心 WordPress 中存在的一些概念，例如 PHP 主题并在无头中使用它们，这样我就可以利用 React 的好处以及我想在前端使用的任何 JavaScript 来模板化我的网站，但仍然是 WordPress 世界中熟悉的概念。

DP：克里斯，你提到浮士德经历了一些变化。 这些变化是什么？ 你知道，杰森提到了他们。 使这种改进成为可能的改变有哪些？

CW：它始终专注于 WPGraphQL。 真正的问题是其他一切。 例如，Faust 的最后一个主要版本在底层使用了一个名为 GQty 的库与 GraphQL 进行交互，这在纸面上听起来非常酷。 当时 Faust 团队的想法是，让我们抽象一下，人们不需要知道如何构建这些复杂的查询。

这个框架应该为你抽象出来。 在纸面上看起来非常好，实际上是因为 WordPress 数据的所有复杂性。 即使是单一的帖子类型也可以有如此多的变化。 也许您将其与类别混合在一起，也许是所有不同的东西。 GQty 只是无法通过它。

最重要的是，当它使用 GQty 版本构建时，确实没有注意到 Jason 所说的路由问题。 谁处理路由？ WordPress 希望根据内容来处理其路由，它是一个内容管理系统，因此所有路由和 WordPress 主要基于内容。

Next.js 是一个前端框架，所以所有的路由都是基于它的，这是一个完全不同的路由如何基于的范例。 Next 上的 /Blog 可能与博客内容无关。 它将转到一组模板。 它将成为可以构建博客的应用程序的一部分。

而 WordPress 上的 /Blog 很可能意味着这些都是博客文章。 在构建时的范例，如果你想让 WordPress 成为一个非常可靠的前端或无头的 CMS，我们必须处理该路由。 我们做这个的另一个转变，就像我在 GQty 版本中所说的那样，我们的目标是必须使用 WordPress 的 JavaScript 开发人员，这看起来很崇高，直到你意识到这是 WP Engine。

我们正在与多年来建立在 WordPress 上的机构打交道，他们现在出于我们稍后可以讨论的各种原因，正在转向无头的事情。 他们知道如何进行 WordPress 开发。 他们了解 WordPress 模板路由的工作原理和模板的工作原理，诸如此类。

我们需要推进这些功能，以便 WordPress 开发人员可以更轻松地使用 GraphQL。 这就是浮士德的目标。 模板层次结构，只是简单地重建了 WordPress 所做的。 现在，如果您想使用 Next 的路由，可以通过多种方法在应用程序中覆盖它，这样您就不会丢失任何东西。

但是对于那些将 WordPress 用作真正的内容管理系统，能够通过内容管理来路由内容的人来说，Faust 会为您处理得更好吗？ 那有意义吗？

DP ：是的。 绝对地。 你知道的，我认为这是一个快速休息的好地方。 您正在收听 Press This，这是一个由 Chris Weigman 和 Jason Bahl 主持的 WordPress 社区播客。 我们会回来谈论 WordPress 和 headless。 敬请关注。

DP：我们带着 Press This 回来了。 你知道，克里斯，就在那次休息之前你提到了一些事情，你提到越来越多的公司陷入无头状态，我知道 WP Engine 已经做了很多研究表明情况确实如此。 我有点想知道，headless 肯定有某种声誉，我认为是企业，当我认为 headless 时，我的想法是否正确。 那是无头的吗？ 它只是企业的工具还是更多站点将要使用的工具？

CW：是的，也不是。 基本上是无头的，尤其是现在使用 WordPress，其中涉及的复杂性意味着您可能有一个完整的团队来构建您需要的东西。

这不是开箱即用的 WordPress，您只是想要您的个人博客。 它可以做到这一点，但到目前为止，为了能够做到这一点，它需要更重的提升。 与 Contentful 相同，与所有这些其他 CMS 相同。 如果你只是想要一些简单的东西，一些你知道的，已经在网络上出现多年的内容类型，headless 可能比你想处理的要多得多。

是严格意义上的企业吗？ 看，不。 盖茨比多年来一直致力于解决这个问题。 稍后您还有另一个播客，Doc with Mastodon。 这是一个我已经参与多年的社区。 大多数人都在使用无头 CMS 的变体，尤其是 Gatsby，但还有 Hugo。 在非常基层的层面上有各种不同的技术。

因此，您最终会遇到基层用户，而最终会遇到大型网站的企业用户，而 WordPress 传统上似乎属于介于两者之间的其他人。 它是那些不想像 Gatsby 用户那样处理 markdown 文件和代码的人，或者你知道，无论如何只是开箱即用的 Gatsby。

但它也不是一个拥有整个 10 人团队来建立个人品牌或个人博客的人。 这将 WordPress 从中间地带出来，很容易将其扩展到两端。 现在你可以轻松地在 GraphQL 之间构建，你拥有所有数据，并且你有一套不断增长的方法来处理这些数据。

Faust 使利用它变得更加容易，并且您可以在一天而不是一个月内构建一些东西。

DP： Jason，Chris 提到了一些我想听听你的想法，我听说这对小团队、像我这样的小博主来说可能不太好，这显然是有道理的，我不需要无头的 WordPress，但是喜欢，我想我想知道的是，无头 WordPress 是否会花费我更多的钱，因为我将不得不拥有一个 iOS 开发人员和一个 WordPress 开发人员？ 是更贵还是更具成本效益？

JB：我想可能取决于你制作的是什么。 如果你正在做，就像你提到的 iOS，如果你正在做一个本地移动应用程序，我的意思是显然无论如何都会有相关的成本，如果你使用来自 WordPress 的数据，那么这并不是一个好的方法，其他而不是无头地做，因为你知道，本机应用程序不呈现 php，所以你必须无头地做。

但就目前而言，如果您正在使用传统 WordPress 构建网络，您可以找到一个主题，您知道一个免费主题或在市场上找到一个主题，下载并安装它，然后您去比赛。 大多数人都会以某种方式对其进行自定义。

所以你通常会有开发成本，无论是你自己还是其他人。 无头 WordPress 与传统 PHP 主题的不同之处之一是，例如，当我启动新的 wpgraphql.com 时，我能够使用为我的 Gatsby 网站提供支持的同一 WordPress 实例。

我正在获取数据，数据正在输出并进入 Gatsby 站点，我能够继续在 CMS 中发布内容，同时为其开发我的下一个前端。 在传统的 WordPress 开发中，您通常必须将您的网站迁移到类似暂存环境中。

在该环境中激活一个新主题，在那里构建您的主题，处理某种内容冻结期，您告诉您的内容创建者，“嘿，今天您不能发布内容，因为我们要迁移，然后我们”我们将设置新的 WordPress 实例，实时实例。” 然后你必须在那里登录并开始正确处理你的内容。

无头 WordPress，我能够在完全不同的前端堆栈上重建我的站点，而不会破坏我实际 WordPress 实例中的任何内容，这是数据和表示的分离，对吧？ 所以我可以去，如果我明天想探索下一个热门技术，就像我可以把目光放在 Svelte 而不是 Next 上一样，我就不必改变 WordPress 中的任何东西。

所以在某些情况下，它实际上可能更便宜，因为启动另一台服务器的整个过程，让您的团队停止编写内容，然后转移到另一个 WordPress 实例，然后开始在那里发布，进行增量迁移，诸如此类，这也是有代价的。

另一件也很有趣的事情是 JavaScript 生态系统确实正在交付。 在我看来，无头技术的共同驱动力之一是基于组件的架构。 还有，React 和 VUE 生态系统中的各种组件库，它们允许您跨项目重用组件。

因此，机构可以构建他们在项目中使用的通用组件，他们可以在一个中心位置更新这些组件，然后将它们安装到多个项目中。 使用 WordPress，这并不那么容易，因为您的 PHP 模板部分和 WordPress 通常与它们所属的项目紧密结合。

在无外设的情况下，您可以拥有一个包含这些组件的 MPM 包，并且多个项目可以更新该包并以更少的努力同时受益。 所以我认为目前，我想说可能成本更高，工作量更大，但我认为像 Faust 这样直到最近才出现的工具正在降低构建无头所需的总体工作量。

而且我认为在不久的将来，构建无头系统可能比不构建无头系统更便宜。

DP： Chris，关于无头 WordPress 的成本，您有什么想补充的吗？

CW：我认为杰森真的一语中的。

这是我喜欢 WPGraphQL 的一件事是我的团队接下来正在用我们所说的扩展 WordPress 的方向，我们的工作名称是 React Gutenberg Bridge，但这在 WordPress 中也是一个问题。 你如何重用这些组件？ 我不想使用“只是组件”这个词，因为它在 WordPress 端的应用与在 JavaScript 端的应用不同，对吧？

但是我们如何跨项目重用代码，无头或 WordPress 的其他方式，而无头确实可以做到这一点。 但我认为可以肯定地说，普通博主只是想发布他们的美食博客，他们自己可能不会处理这个问题。 这在很大程度上是一个代理问题。 是不是成本更高？

也许，也许不是，但这就是当我们谈论成本在哪里时变得复杂的地方？ 因为它是您想要使用数据的不同类型。

DP：是的，绝对。 你知道，来自报纸背景，在双子城和纳什维尔的周刊工作，杰森，我可以想象告诉你的 56 家报纸一天不出版会是什么感觉。

今天没有消息，因为我们正在更新网站。

JB：是的。 我的意思是，我们确实经历过那些时期，对吧？ 就像我在那里受雇时一样，他们不在 WordPress 上，所以我工作的一部分是将他们从另一个系统转移到 WordPress。 所以肯定有几天，好吧，它会在 WordPress 日上线。 停止你正在做的事。 正确的。

所以肯定有这样的时期，或者我们也必须处理这样的问题，好吧，他们在旧系统上发布到昨晚午夜，但我们在两天前准备好了 WordPress。 所以现在我们必须像 Delta 迁移那样做，并确保所有数据仍然同步，这样，你知道，这些过程肯定会产生技术和人力成本。

DP：是的。 而且我认为还有很多，当您仍在使用 WordPress 时，您仍然可以获得可以节省成本的生态系统。 您不必构建 SEO 工具。

您可以使用 Yoast SEO 插件或其他任何东西。 即使你是一个 Headless 站点，我假设大多数插件仍然可以工作，只要它们不是前置的。

JB：是的。 这其实是一件很有趣的事情。 所以新的浮士德本身就是用插件架构构建的。 所以开箱即用，它会附带一个客户端，它使用 Apollo 客户端，这样你就可以从 WPGraphQL 获取数据，你可以获取你的 WordPress 数据，但是你可以创建插件，这样，假设你做了，就像你一样提到，在您的 WordPress 网站上安装 Yoast SEO。

您可以添加 Yoast 插件。 它还不存在，但很快就会存在。 您可以在前端为 Faust 添加一个 Yoast 插件，它知道如何处理该数据，对吧？ 所以会有人的能力，有些我们可能会生产和支持，但有些，社区也可以生产和支持 Faust 方面的插件，这样你只需要一行代码，就可以添加这个插件为您的无头前端获取 Yoast 等功能。

这是我不认为任何其他无头前端真正具有 Faust 正在接近它的相同概念的东西。 所以我认为插件，我认为它是 WordPress 开发人员熟悉的另一件事。 它从 WordPress 中引入了熟悉的概念，但将其与现代 JavaScript 前端堆栈联系起来。

DP：那是 Press This 最后休息的好地方，当我们回来时，我们将结束与 Chris Weigman 和 Jason Bahl 的谈话。 敬请关注。

DP：您正在收听 Press This，一个 WordPress 社区播客。 我是你的主人，Doc Pop。 今天我们谈论的是 WPGraphQL、Faust，以及如何为您的无头 WordPress 网站提供动力。 就在休息之前，我们正在谈论 Faust 和插件，我只是想向大家抛出一些随机问题，看看这里是否有好的答案。

但是克里斯，我有点想知道 Faust 是否有任何潜力，我知道它是一个无头平台，但是否有任何潜力，比如 WordPress Faust 主题，至少让你设置类似，这是您需要的插件，这里是开箱即用的所有插件。

CW：当然。 事实上，我们已经拥有了。 我们将其称为蓝图，因为它与 Local 密切相关。 在像 WP Engine 这样的平台上发布之前，大多数人都会对这些东西进行一些调整。 所以我们借用了Local的名字Blueprints。

对于新的浮士德，我们有一个叫做 Portfolio 的，它基本上是一个完整的投资组合主题，我们正在研究一个非常空白的脚手架，供机构使用。 一旦你掌握了窍门，你可能会想自己定制一切。 因此，脚手架将是项目最佳实践，将其旋转起来，然后您就可以用它来做您自己的所有事情。

长期以来，我们一直在大量讨论无头主题商店，ala Blueprints。 我们没有人力，所以这还有一段路要走，但这绝对是我们正在考虑的事情，我们希望看到发生。

DP：是的，想想这很酷。 这是一个完全不同的生态系统。

你知道的，Jason，我之前采访过你，我确信这个问题一直出现，但每次我听到 WPGraphQL，我都在想这听起来很像 REST API 所做的。 实际上，这听起来比 REST API 的功能强大得多，而且 REST API 是核心的一部分，我只是想知道，您认为 WPGraphQL 应该成为 WordPress 核心的一部分吗？

JB：也许有一天。 我认为我们还没有。 当东西在 WordPress 核心中合并时，可能除了 Gutenberg 之外，创新就会停止。 例如，REST API 仍然有一个我向人们指出的错误，我认为从 2016 年起它仍然存在。所以我的意思是，当内容进入核心时，您将添加一个功能集到 40% 的网络和所以必须以更慢的速度进行更改，如果它是一个插件，你可以让人们选择他们想要选择的版本，你可以更快地迭代，因为他们可以选择最适合他们项目的版本。

在 core 中，如果您更新 core 并且它包含重大更改，您可能刚刚破坏了 40% 的网络。 所以 GraphQL 是一个规范，它也与 WordPress 无关。

正确的。 因此 GraphQL 规范仍在不断发展。 随着它的不断发展，我们希望跟上最新最好的 GraphQL 规范。 如果我们今天将 WPGraphQL 合并到 Core 中，并且 GraphQL 不断发展，WordPress 将停留在 GraphQL 的 2022 版本，而世界其他地区则使用 2030 版本或其他版本。 对我来说，我认为在某些时候让它像 WPCLI 一样被认可是做 X 事情的官方方式可能是有意义的。

就像您可以为 WordPress 构建您自己的 CLI 客户端一样，但社区承认 WPCLI 是官方的东西。 它不是 WordPress 核心的一部分，但它被 WordPress 基金会和大多数 WordPress 社区认可为官方的东西。 因此，在某些时候，像这样识别 WPGraphQL 可能会很好，就像如果你打算做无头 WordPress，就这样做。

它仍然是一个插件。 这就是我的想法。 可能有一段时间 GraphQL 感觉很完美，它并没有真正被迭代，也许那个时候我们会考虑它。 但此时 GraphQL 规范出现了一些问题，这将导致 API 发生重大变化。

所以把它作为一个插件对我来说仍然有意义。

DP：马上。 是的，你提到过 WPCLI，但我一直忘记，就像他们只是觉得它是核心的一部分。 无论感觉如何，都像官方一样。 所以是的，就像，哦，是的，这就像这个独立的东西，就像 WPGraphQL 目前一样。

这是一个很好的类比。 所以我要，我要在这里结束。 和你们两个聊天真的很棒。 如果听众有兴趣关注你们中的任何一个，您可以关注@JasonBahl 和@ChrisWeigman。 如果可以的话，我们会将 Twitter 句柄放在节目描述中。 您一直在收听 WMR 上的 WordPress 社区播客 Press This。

在下周的节目中，Automatic 的产品联络人 Anne McCarthy 将讨论网站编辑和 6.1 的变化以及 6.2 的新内容。 再次感谢收听 Press This。

你可以在 Twitter @thetorquemag 上关注我在 Torque 杂志上的冒险经历，或者你可以去 torquemag.io，我们每天都会在这里提供教程、视频和采访。 因此，请查看 torquemag.io 或在 Twitter 上关注我们。 您可以在 Red Circle、iTunes、Spotify 上订阅 Press This，也可以每周直接在 wmr.fm 上下载。 我是你的主持人 Doctor Popular 我通过我在 WP Engine 的角色支持 WordPress 社区。 我喜欢每周都在 Press This 上关注社区成员。