无头 CMS：带有 WordPress 的 Gatsby JS
已发表: 2020-05-04众所周知，WordPress 覆盖了全球前 100 万个网站中的大约三分之一，在内容管理系统中拥有超过 50% 的市场份额。 就在 2016 年，WordPress 决定引入 REST API 来为其他应用程序提供改进的对 WordPress 数据库中内容的访问。 结果，为开发人员提供了利用 WordPress 作为无头 CMS 的能力。
这不可避免地意味着工程师将不再局限于使用 WordPress 的传统表示层（前端），而是现在可以利用任何前端应用程序来传递他们的数据。 鉴于此，本博客的大部分内容将探讨 WordPress 和 Gatsby.js 在 Headless CMS 效果方面的关系。
CMS 简史
当我们退后一步了解无头 CMS 革命时，我认为回顾内容管理系统 (CMS) 的历史是值得注意的。 传统上，在 90 年代初期，静态网页是执行网站的主要方式，网站管理员可以直接编辑 HTML 文件并通过 FTP 将它们上传到服务器。 最终，在 90 年代中期，Web 技术开始发展，内容变得更加动态，导致出现了第一个单一的内容管理系统。
从本质上讲，Monolithic CMS 是一个软件应用程序，其中包括在 Web 上编辑和发布内容所需的一切。 此类系统中的第一个仅限于 EpiServer 等企业，但是后来出现了 WordPress、Drupal 和 Joomla 等开源变体。 其余的都是历史，因为 WordPress 随着时间的推移获得了最大的市场份额。
然而，在智能手机革命后期，移动设备开始影响 Web 内容的消费和交付方式。 这对旨在为笔记本电脑和台式机提供 Web 内容的传统单体 CMS 构成挑战。
为了缓解这种情况，响应式设计应运而生，从而使网站布局适应屏幕尺寸。 因此，这也提供了将内容管理与显示层分离的机会。 这就是我们的无头 CMS 的用武之地。
无头 CMS
如前所述，无头 CMS 是一种没有表示层的 CMS。 因此，内容通过 API（RESTful 或 GraphQL）传递到单独的前端应用程序，然后再呈现它。 API 使用各种工具和编程语言，使内容可用于任何渠道和设备，具有更高级别的安全性和可扩展性。
从本质上讲，CMS 与前端问题解耦，这反过来又使开发人员能够使用可用的最佳技术为最终用户构建丰富的体验。 目前大多数 CMS 都支持“无头”或“解耦”模式，这为 Gatsby 网站铺平了道路。
因此，要利用无头 CMS，您必须先构建您的网站或应用程序，然后使用 CMS 的 API 插入您的内容。
WordPress Headless CMS 执行
关于上面分享的事件的年表，我们已经看到 WordPress 如何最终实现了无头 CMS。 WordPress 包含一个 API（应用程序编程接口），允许您使用插件（本质上作为“应用程序框架”）对其进行扩展。 具体来说，这是通过 REST API 实现的，我们稍后会介绍。
然而，WordPress API 的关键概念之一是钩子。 基本上，钩子允许插件改变 WordPress 的核心功能。 实际上，钩子的工作方式是当 WordPress 中的某个事件发生时（例如，页面加载或后期编辑），WordPress 调用某个钩子来运行该函数。
具体来说，钩子分为“动作”和“过滤器”。 可以利用操作在某些事件中运行某些 PHP 函数，尽管这些函数不需要返回任何内容。 而过滤器可用于运行 WordPress 在某些事件期间传递数据的函数，这些函数将数据作为参数并返回数据的修改版本。
WordPress 和 REST API
Representational state transfer (REST) 基于 HTTP 协议，并提供统一的接口语义来创建、读取、更新和删除数据 (CRUD)。
通常，WordPress 中的 REST API 执行使开发人员能够通过发送和接收 JSON（JavaScript 对象表示法）对象来远程访问 WordPress 数据库中的数据。 因此，这为开发人员提供了从非 WordPress 设计的其他应用程序创建、读取、更新和删除 WordPress 数据的机会。 例如，JavaScript Web 应用程序或原生移动应用程序。
但是，随着我们深入了解 Headless WordPress CMS 与 REST API 和 Gatsby 的关系，我们需要注意 WordPress API 的一些基本概念：
- 路由和端点：路由是您可以通过 HTTP 调用访问的路径，而端点是映射到该路由的 HTTP 方法（例如 get、post、put 或 delete）。
- 请求：当您向已注册的 REST 路由发起 HTTP 请求时，WordPress 会自动创建一个请求对象。 请求中指定的数据将决定您将得到什么答案。
- 响应：响应对象是您在发出请求时收到的数据。 它可以包含请求的数据或错误消息。
- 架构：架构是指端点中的数据结构。 每个端点可以返回的数据结构可能略有不同或显着不同。 因此，模式将确定端点可以返回的所有可能属性以及它可以接收的所有可能参数。
- 控制器类：控制器类使开发人员能够管理和注册端点和路由，同时还允许他们处理请求、利用模式和生成响应。
反应“框架”
当我们现在深入了解 Gatsby.js 和 WordPress 的关系时，为了获得更多的背景信息，我们必须从更多的历史基础中解读这种技术格局。 React 是这个故事的关键，因为它是增长最快的 JavaScript 前端库/框架。 因 Facebook（其核心开发人员）而闻名的其他大型网站使用 React 作为其前端，例如：Airbnb、Netflix、Dropbox、BBC、PayPal、Reddit、Salesforce、Squarespace 和 Tesla。
因此，由于 React 在实践中是一个库（因为它仍然缺乏成熟框架的显着特征），这意味着可以在它之上设计其他“框架”。 结果，其中之一就是 Gatsby.js。
介绍盖茨比
据其母网站介绍，Gatsby.js 是一个基于 React 的免费开源 JavaScript 框架，可帮助开发人员构建快速的网站和应用程序。 原则上，Gatsby.js 从应用程序生成静态 HTML 页面以进行初始加载，然后作为单页 React 应用程序 (SPA) 继续执行。
Gatsby.js 属性
在这种情况下，Gatsby 利用渐进式 Web 应用程序 (PWA) 原则仅获取首先需要的元素，然后稍后在后台加载应用程序的其余部分。 此外，为了确保只加载所需的数据，Gatsby 利用 GraphQL 查询语言（也由 Facebook）从源加载数据。 它还保持出色的图像优化。
所有这些功能的合并为开发人员提供了创建最快的网站和 Web 应用程序的必要工具，因为它只加载关键的 HTML、CSS、数据和 JavaScript。 因此，一旦加载了页面，Gatsby 就会为链接页面预取资源，因此浏览网站感觉非常快。
此外，由于页面是在编译时生成的，在线放置之前，您不再需要强大的 PHP 服务器，并且可以提供静态文件（HTML、JS 和 CSS，直接来自存储桶）。 此外，由于 Gatsby 由 React 提供支持，您将能够使用组件很好地构建所有内容。 这种模块化方面允许开发人员轻松地重用组件。
其他重要的开箱即用 Gatsby 功能包括：
- 静态站点生成器
- 离线访问
- 预取链接页面
- 页面缓存
- 没有多余的代码获取
- 导出为代码
- 热重载内容
- 热重载代码
- 组件化
- 单向数据绑定
- 声明式 API 数据查询 (GraphQL)
- 声明式用户界面
- 渐进式图像加载
- 响应式图像加载
- 关键 CSS 的内联
- 字体自托管
- 无服务器
- 资产管道
- CSS 扩展 (SaSS)
- 高级 JavaScript 语法
- React 组件生态系统
盖茨比插件
本质上，Gatsby 插件基本上是使用 Gatsby API 的 Node.js 包。 这些插件可以添加数据源、将数据转换为其他格式并添加第三方服务。 虽然 Gatsby.org 维护了一个插件库，其中包含许多由核心 Gatsby 团队或第三方制作的插件。 理想情况下，要为 Gatsby 项目安装插件，开发人员在其 UNIX 终端上使用节点包管理器 (NPM) 并运行命令 npm install。
GraphQL 的来历与盖茨比有关。
GraphQL 围绕这样一个想法，即您可以向 API 准确地描述您想要的数据，并且您会收到准确的数据。 因此，它比 REST 更有效。 为此，Gatsby 采用了 Webpack 和 GraphQL。 更重要的是，使用 GraphQL 作为查询语言，一切都在客户端执行查询时定义，客户端不知道应用程序的底层工作。
这种独特的实现使开发人员能够将任何数据源连接到 Gatsby。 例如，博客文章可以来自 Markdown 文件、Google 表格，甚至是另一个 WordPress 网站。 因此，通过内容交付提供增强的灵活性。
Gatsby-WordPress 机制（源码插件）
随着我们进一步解开这种关系，我们需要了解源插件。 源插件是在 Gatsby 的数据系统中工作的特殊插件。 顾名思义，它们从不同位置（本地或远程）获取数据。 因此，数据随后被转换为 Gatsby 所说的节点和节点字段。 基本上，节点字段代表一个节点内的单个数据，最终，这些节点可以通过 GraphQL 查询访问。
在同样的广度上，通过源插件，Gatsby 支持数十种无头 CMS 选项，为工程和内容团队提供其首选管理界面的舒适度和熟悉度，以及使用 Gatsby、GraphQL 和 React 构建一个改进的开发人员体验和性能优势前端。
“Gatsby-source-WordPress”插件由 Gatsby 核心团队构建和维护，并从自托管的 WordPress 站点或 WordPress.com 中提取数据。 它还需要对 Word-Press.com API 进行 OAuth 身份验证，并且还允许开发人员查询响应式图像。
本质上，该插件支持 WordPress REST API 上的所有实体，例如帖子、页面、标签、类别、媒体、类型、用户、状态、分类、站点元数据和自定义帖子类型。 此外，除了注册到 REST API 的其他帖子元之外，还支持高级自定义字段 (ACF) 实体和 Polylang 和 WPML 语言信息。
因此，使用此插件，开发人员可以选择要获取的路由，尽管它默认获取 wpjson 的所有端点。 因此，开发人员可以使用上述机制使用 GraphQL 从 WordPress 中获取数据。
在实践中，“Gatsby-source-WordPress”工具为所有帖子和其他实体提供了一个 slug。 因此，工程师需要做的就是创建页面调用'createPage'函数。 这是在 Gatsby-node.js 文件中执行的，通常首先对数据源运行查询，然后为每个找到的节点调用“createPage”，然后设置一个模板文件用作组件。
CI/CD 和应用程序发布自动化。
在使用 Gatsby 实现无头 WordPress CMS 时，如何执行部署非常关键。 通常，此类执行需要使用应用程序发布自动化 (ARA) 自动部署应用程序。
通常，ARA 需要主要功能：
- 数据、应用程序代码和工件的部署。
- 为每个环境部署特定配置
- 用于自动化任务和部署步骤的流程工作流设计。
- 最后，环境建模和/或配置二进制文件
由于 Gatsby 生成静态站点，因此必须设置 ARA 管道，以便在 WordPress 中更新内容时，可以在 Gatsby 站点中相应更新。 通常，持续部署仅在代码更改时触发，但是，对于这种情况，最好在数据更改时触发它。 因此，为此，我们建议使用 Netlify 因为它具有出色的内置持续部署功能，并且易于设置。
使用 GraphQL 和 gatsby-source-WordPress 从 WordPress 查询
例如，gatsby-source-WordPress 的工作方式是首先使用 REST 获取端点上的所有内容。 然后它将基于该数据生成一个内部 GraphQl API。 随后，它将通过您的查询并从该内部 GraphQL API 收集数据。 因此，基本上，您的构建仅以您要求的数据结束，没有别的。
使用 Gatsby.js 开发无头 WordPress 的优势
由于我们已经通过 Gatsby 接触了 Headless WordPress 开发，我们现在可以分解这种技术方法的优点。 这应该基本上指导您决定是否采用 Gatsby！
- 第一个好处是能够拥有一个静态的、预呈现的站点。 这是呈现网页的最有效方式，并且由于 Gatsby 使用 GraphQL 来执行所需的最少数据量，这为初始加载后的时间提供了一些额外的效率。
- 改进的 SEO 可见性：静态页面易于搜索引擎阅读，因为所有内容都是预渲染和可索引的。 这是一个积极的方面，与其他无头机制相比，使用 JavaScript 呈现页面是关于搜索引擎优化 (SEO) 的问题。
- 相对较快的开发速度：与其他无头方法相比，Gatsby 具有一种统一、易于理解的数据获取方式，无论来源如何。 这使得开发变得相当简单，因为您可以专注于您的实际站点并让 Gatsby 完成大部分繁重的工作。
- 更便宜的托管：您可以在任何地方托管 Gatsby 应用程序，因为它只提供静态文件，从而减少托管费用。 此外，由于 WordPress 仅在构建过程中被调用，而不是在用户会话期间被调用，因此它也可以托管在负担得起的托管解决方案上。
- 增强的安全性：一般来说，静态站点生成器非常安全，因为没有直接连接到数据库、依赖项、用户数据或其他敏感信息。
- 无插件：从非开发人员的角度来看，WordPress 非常容易操作，因为有可用的插件。 但是，这限制了自定义功能的实现。 不幸的是，太多的插件也会减慢网站的速度，因为它变得沉重且难以呈现。 Gatsby 执行基本上绕过了所有这些瓶颈。
更多可以激发您考虑使用 WordPress 的 Gatsby 的方面：
- 易于管理的 WordPress 管理面板。
- 准备使用用户登录系统和授权。
- 使用 Gatsby 和 Gutenberg 编辑器，您可以构建拖放式 Gatsby 站点构建器。
使用 Gatsby.js 开发无头 WordPress 的缺点
- 更新限制：当内容从头开始更改时，它会限制您的网站可以更新的频率。 此外，如果您的站点包含大量数据，则运行 Gatsby 构建可能需要长达 10 分钟，这对于频繁更新的站点来说可能是一个问题。
- 定期更新 Hustle：此外，由于 Gatsby 是一个静态站点生成器，它不能只是“编辑”，因为即使是很小的文本更改也需要新的部署。 因此，如果您的页面需要许多动态的每日内容更改，这可能会变得耗时且繁琐。
- 延迟：您通常需要等待几分钟才能看到内容上线时的变化。
- 缺乏预览：与传统的 WordPress 应用程序不同，您在 Gatsby 中没有任何类型的预览。 可悲的是，这是内容创作者在 Gatsby 中发现的最大问题。 您将需要编译所有内容，可能使用编译网站并将所有内容放到网上的 Gitlab CI/CD 管道。
- 陡峭的学习曲线：一般来说，如果你想同时使用 Gatsby 和 WordPress，你需要对 PHP 和 JavaScript 语言都比较熟悉。 由于 Gatsby 合并了 React 和 GraphQL，这对许多人来说可能是一个陡峭的学习曲线。
最后的想法。
总之，由于 Gatsby 的性能和业务优势，越来越多的公司将 Gatsby 作为其技术堆栈的一部分。 尽管重要的是要记住，通过将 Gatsby 与 WordPress 合并，WP 仅成为后端，这意味着您将失去它的一些功能和能力。
此外，具有 WordPress 开发经验的开发人员会发现 Gatsby 是一款出色的工具，具有现代性能、可扩展性、安全性和开发速度优势。 所有这一切同时允许他们保留 WordPress 提供的熟悉的内容创建用户界面。
但是，在启动这项技术之前，应该始终考虑他们的项目规范和目标。 例如，如果重点是可扩展性、性能、开发速度、长生命周期，Gatsby 就可以。 但是，如果重点是为非程序员内容创建者提供更高的灵活性和工具，并以秒或分钟为基础更新内容，那么您可以考虑另一种方法。