WordExpress 项目实验将 GraphQL 引入 WordPress

2012 年，当 Facebook 开始将其 HTML5 驱动的移动应用程序重新架构为原生 iOS 或 Android 应用程序时，该公司发明了 GraphQL。 这种新的开源查询语言被誉为 REST 的直接替代品。 GraphQL 提供了一种更有效的方式来支持每天在 Facebook 应用程序之间发生的大量交互，但它与数据库无关，并且可以在 Facebook 之外使用。

尽管 GraphQL 仍然相对较新，但 Intuit、Coursera、Pinterest 和 Shopify 等大公司正在生产中使用它。 上个月 GitHub 宣布 GraphQL 支持其 GitHub API，以解决其 REST 架构的一些缺点。

GraphQL 提供了一种新的方式来构建从客户端到服务器的通信，从而更高效地获取数据。 Petr Bela 在他的文章 REST API 时代的 GraphQL 中总结了这两种架构之间的区别：

GraphQL 的强大来自一个简单的想法——不是在服务器上定义响应的结构，而是为客户端提供了灵活性。 每个请求都指定了它想要返回的字段和关系，GraphQL 将为这个特定的请求构建一个定制的响应。 好处：只需要一次往返即可获取所有可能跨越多个 REST 端点的复杂数据，同时只返回实际需要的数据，仅此而已。

上个月 Facebook 宣布 GraphQL 正在退出“技术预览”阶段，现在已经准备好生产。 它已经在许多不同的编程语言中实现，并且已经被希望以更有效的方式访问数据的公司所采用。

WordExpress 将 GraphQL 引入 WordPress

Ramsay Lanier 是一名 JavaScript 前端开发人员，在华盛顿特区的 nclud 工作，他创建了一个基于 GraphQL 的 WordPress 实现，称为 WordExpress。 Lanier 不喜欢 PHP，也不喜欢使用循环或模板，所有这些东西在历史上都构成了 WordPress 前端开发的大部分内容。 他将 WordExpress 创建为一个 Node.js 应用程序，目的是用 JavaScript 替换 PHP，以实现 WordPress 的表现方面。 它在后端使用 Express，在前端使用 React 组件。 GraphQL 位于两者之间，用于从 WordPress 数据库中检索数据。

“当我最初提出 WordExpress 的想法时，我想使用 REST API，但我发现现有的端点不是我想要的，”拉尼尔说。 “我最终不得不编写一堆自定义端点并将调用链接在一起。 所以我想我应该试试 GraphQL。”

他发现 GraphQL 比 REST 更高效，因为它减少了到服务器的往返次数，让开发人员可以专注于客户端真正需要的数据。 Lanier 强调了与 WordPress 网站相关的好处：

使用 GraphQL，客户端通过 GraphQL 查询确定它需要的确切数据。 GraphQL 查询有一个自定义解析函数，用于确定如何检索数据。 在该功能中，您甚至可以访问多个数据库。 例如，对于 WordPress，您有一个 MySQL 数据库，但您可能还有一个 Mongo 数据库，用于存储其他不需要的关系数据的应用程序。 在 GraphQL 解析功能中，您可以调用以从两个数据库中检索数据，并在一次服务器往返中将其发送回客户端。

当前形式的 WordExpress 是构建使用 WordPress 进行管理的 JavaScript 驱动的应用程序的良好起点。 Lanier 说，这种开发设置使他能够比使用 PHP 模板更容易地创建网页和应用程序的组件。

“使用 React，每个组件不仅包含显示内容的标记，还包含该组件的样式、它工作所需的数据以及任何交互逻辑——所有这些都在一个或两个文件中，”他说。

WordExpress 的当前挑战：插件兼容性和服务器端渲染

尽管更高效的查询具有所有令人兴奋的好处，并且可以使用 JavaScript 驱动的前端，但 WordExpress 项目仍面临许多严峻的挑战，除了简单的博客安装之外，它在生产环境中使用起来很麻烦。 它与绝大多数 WordPress 插件不兼容，因为大多数插件都是用 PHP 编写的。

“基本上，我已经更换了整个前端，这意味着任何影响前端的插件都不会做任何事情，”拉尼尔说。 “但是，您当然可以利用影响管理方面的现有插件（例如高级自定义字段或 AWS S3 插件）。 任何操纵 WordPress 数据如何存储在 MySQL 中的东西仍然可以使用——您只需要修改 GraphQL 模式和查询即可使用它们。”

另一个主要挑战是让服务器端渲染工作，这是处理 SEO 和元标记等事情所必需的。 WordExpress 使用 Apollostack 来获取数据并将其传递给 React 组件，它最近才添加了对自动服务器端渲染的早期支持。

“我已经从使用 Facebook 的 Relay 转为使用 ApolloStack，”Lanier 说。 “两者都是相当新的技术，我不确定是否真的想出了如何很好地处理服务器端渲染。 我已经有几个月没有研究过了，ApolloStack 的进展很快，所以他们现在可能已经想通了。”

目前，WordExpress 只是一个概念验证，Lanier 表示他没有计划尝试支持现有插件。 鉴于 WordExpress 目前无法利用主题和插件，这是 WordPress 生态系统中一些最好的部分，Lanier 说使用这个堆栈的开发人员可能更感兴趣的是保留 WordPress 管理方面的力量。

“我喜欢 WordPress 管理员，”他说。 “它非常强大且易于使用来管理内容。 WordExpress 将成为任何想要仅使用 JavaScript 构建 WordPress 应用程序的 JavaScript 开发人员的起点。”

Lanier 使用 WordExpress 的目标是把它变成一个 npm 包，可以在各种不同的 React 项目中重用。 他已经发布了两个协同工作的 WordExpress npm 包：wordexpress-schema（处理 GraphQL 模式和连接设置）和 wordexpress-components（目前包含前两个组件，WordExpressPage 和 WordExpressMenu）。 由于该项目是基于 Node.js 构建的，因此开发人员可以使用他们想要的任何 npm 包，这是对有限插件兼容性的一种安慰。

GraphQL 和 WP REST API

许多预测 GraphQL 将直接替代 REST 的人也认为两者可以共存。 事实上，Facebook 最近编写了一个在 GraphQL 中包装 REST API 的指南。

“如果 GraphQL 被证明是有效的，它很可能会与 REST API 共存，”Petr Bela 说。 “有些 API 将使用 REST，有些将使用 GraphQL。 有些人可能同时支持两者。” 他预测，整个行业从 REST 完全切换到 GraphQL 需要数年，甚至可能需要十年时间。

Lanier 的 WordExpress 最近在 GitHub 上获得了 1000 颗星，是目前唯一公开探索 GraphQL 驱动的 WordPress 实现的开源项目。 在 GitHub 上粗略搜索一下，发现许多其他人正在尝试类似的设置。 幸运的是，GraphQL 不需要对 WordPress 核心进行任何更改，以使站点能够使用 API 来查询数据库。

Lanier 表示，他感谢那些试图将 WP REST API 合并到核心中的人所做的工作，并且不认为 GraphQL 的实现会对此构成威胁。

“我认为他们使用 REST API 所做的工作是件好事，”他说。 “他们绝对需要迈出这一步。 REST 已经存在很长时间了——GraphQL 仍然很新，所以走 REST 路线是有意义的。 此外，更多的人知道如何使用它。 GraphQL 的好处在于您可以使用它来包装 REST API，因此它们可以共存。”

WordExpress 超越简单概念验证的可能性取决于社区的反馈。 拉尼尔说，开发人员通过分叉和提问来表现出对 WordExpress 的兴趣。

“人们正在使用它，玩弄它并（希望）把它变成自己的，”他说。 “我认为兴趣就在那里。 但是，要使其真正可行，您需要整个开发团队使其成为一流的选择。”

Lanier 最近接受了一份新工作，他正在使用 100% 的 React，并且有一段时间没有机会使用 WordPress，但他表示他愿意探索合作以使 WordExpress 生产做好准备。

“如果人们真的很感兴趣并想聚在一起将其发展成一个可行的解决方案，我会 100% 参与其中，”他说。

想要测试它并开始使用 WordExpress 进行开发的开发人员需要对 React 的工作原理有基本的了解。 Lanier 编写了有关如何设置 GraphQL 实现以及如何扩展 GraphQL 查询和数据库模型的详细文档。 WordExpress.io 站点是代码的实时演示，您可以在 GitHub 上找到该代码。