去无头：用例和它的好处

已发表: 2022-03-10

快速总结↬无头选项流行的驱动因素之一是对用户体验质量的期望不断提高。我们拥有丰富的工具来帮助开发人员快速构建事物，从而快速预期结果。无头模式可以让您的团队完全控制用户体验，而不是与无法完全满足您需求的大型工具搏斗。

回顾 Web 开发的这些年，我使用了几十种不同的 CMS 工具，既有现成的，也有自制的。我一直在部署和构建大量WordPress 站点和插件，以及 .NET 中提供全方位服务的 CMS 站点的扩展。但对我来说，当我第一次听说 headless 时，一切都变了，而现在，多年后，我在headless 生态系统中感觉再舒服不过了。

这种热情并非凭空而来。虽然理解所有无头选项似乎令人生畏，但我一直在为不同环境中的不同无头选项改进自己的策略，并使自己非常熟悉无头空间中的常见嫌疑人。转向无头模式帮助我避免了因大型一体化系统的限制而遇到的障碍。

将功能区分开来，以便您今天可以实现复杂的目标并准备您的应用程序以在未来轻松发展，这让我高枕无忧。很高兴为私营公司和加利福尼亚州政府基于无头解决方案构建的 Web 服务的成功部署和迭代做出贡献。

在本文中，我很乐意分享这些年来我学到的一些有用的指示和指导方针，希望它们能帮助您理解无头世界，并为您的项目找到合适的候选人。但在我们深入研究之前，我们需要及时回顾一下，以了解无头带来了什么。

无头之前

就在几年前，我们的工作流程似乎专注于一系列工具、堆栈和技术。对于 CMS，我们主要使用多合一工具。它们包括内容创作和内容查看功能。

文本模式 CMS — 你们中的一些人可能还记得很好的 ol' Textpattern、PHP-Nuke、Mambo 和其他 —— 一些在 2000 年代初发布的第一个 CMS。

这些工具的用户被后端附带的前端所困。你定制事物的能力是有限的。您可以安装插件，但它们都必须为您的工具构建。您可以编写自定义代码——但只能使用您的工具所基于的语言并在其约束范围内。

在过去的几年里，这一切都发生了变化，无头 CMS在整个行业中获得了关注。

专业工具的复兴

今天，我们拥有大量专门用于创作或内容呈现视图的工具。 无头 CMS专注于内容创作部分，并提供了一种连接单独的内容呈现工具的方法。缺乏面向用户的前端使其无头，并使其能够灵活地通过其 API 使用任何工具。

能够从头开始设计自己的前端为许多开发团队带来了自由。您可能拥有一支精通工程师团队，他们擅长在 Vue.js 中交付流畅的单页应用程序，或者使用 11ty 快速渲染、防弹的静态生成网站。所有最新的 Web 开发框架都旨在轻松处理可以从任何无头 CMS 提供的结构化数据。

无头 CMS 是一种专注的工具。与一体化解决方案相比，它的责任更少。无头 CMS 提供的 API 端点在系统之间提供了清晰的分离，因此您可以随着事情的发展独立地交换前端或后端架构。您的产品在增长，工具生态系统在扩展，新方法变得可用。您的后端和前端要求将发生变化。如果您有无头设置，您将能够更轻松地适应，因为您的前端和后端已经被 API 完全分开，您可以独立升级它们。

无头适合我吗？

最值得注意的是，headless 为您提供了满足挑战性要求所需的灵活性。如果您必须对多合一产品进行大量修改，则可能很难实现您的目标。将无头工具与更小、不同或自制的前端相结合可能是交付所需设计和用户流程的最简单方法。

如果您想微调产品结帐流程的每一步，您可以使用无头商务选项来实现这一点，
如果您想对 Time to First Byte 进行大量优化，您可能需要使用静态站点生成器，该生成器基于无头 CMS API 在更改时重建内容，
如果您托管自己的工具并且对安全性持谨慎态度，您可能希望将您的创作环境锁定在防火墙后面，并从更简单的基于 Jamstack 的前端无头地使用它，
如果您为各种客户端提供相同的内容，例如 Web、本机应用程序或第三方小部件，您可以构建它们，使它们都可以通过同一个 CMS 进行无头通信。

如果您可以使用多合一工具完美地满足项目要求，那么无头选项对您来说可能有点矫枉过正。同样，如果您的团队对您当前的多合一解决方案非常满意并且精通，那么您真的不需要担心拆分前端和后端工具。但是，如果相反，您遇到了工具的限制，那么无头模式将使您能够直接解决您的痛点。

示例：无头电子商务

让我们看一个特定的无头选项：您可以将现有的电子商务平台（例如 Shopify）集成为一个完整的流程来接管整个结帐流程，或者您也可以使用 Shopify 提供的无头选项。

在前一种情况下，您的设计将严重依赖 Shopify 的模板和开箱即用的功能，因此可以调整结帐流程，但非常有限。
在后一种情况下，您可以以任何您喜欢的方式设计结帐流程，并且您将依靠 Shopify 仅执行金融交易。

显着的区别在于，无头选项将要求您构建用户看到的每个视图。再一次，如果这听起来像没有好处的麻烦，那么您可能不需要无头解决方案。

需要无头版本的团队将欢迎它提供的自由。您的设计将没有任何限制，您将能够控制每个视图的每个像素。您将完全控制在用户设备上执行的所有代码，因此您可以跟踪、优化和加速每一次交互。

同时，您仍然将交易处理留给您的无头电子商务解决方案，因此您可以从他们的后端系统中受益。

底线是：如果您正在努力解决当前电子商务解决方案中的瓶颈——无论是繁重的前端、复杂的 UI 还是无法访问的设计——那么无头选项将使您的团队更容易解决这些问题。同样，如果听起来它可以让您的团队更轻松地通过更快、更顺畅地部署新功能来增加您的转化渠道，那么考虑无头选项也是一个好主意。

使用单一平台避免锁定

看看当今前端的状态，在前端和后端工具的选项不断扩展的世界中，将您的创作和内容交付工具解耦是构建事物的最安全方式。创作和阅读环境具有不同的需求集的情况并不少见，因此能够选择分别解决这些需求的工具可以为双方提供更好的选择。

基于 Jamstack 的设置由 API 启用，因此它们通常与无头 CMS 相关联。不过，做出无头选择并不需要 Jamstack 前端。当然，如果您愿意，您仍然可以运行一些服务器端代码。

例如，我帮助构建了一些运行 Node.js 和 Express 的站点，这些站点使用Wordnik.com等后端 API，并且这种流行的模式运行顺利。 通过 API 访问您的数据可以在生产中放弃您的服务器端代码，因此如果这在您的项目中有意义，您可以轻松地采用 Jamstack 等客户端方法。

“一体式”解决方案的问题在于，它们每个人都有很多承诺。例如，您必须致力于支持数据库和编程环境，或者选择支持的 SaaS 供应商；此外，您的设计更改必须在可用的主题和插件中进行。

有了无头，我们就摆脱了被锁定在一个平台上。因此，如果您需要为您的网站使用新的前端框架，或者您想要移除昂贵的生产基础设施并使用静态站点生成器，或者可能想要切换您的 CMS 而无需从头开始重建所有前端 - 与替代方案相比，当您使用无头选项时，您可以以更少的摩擦来实现所有这些。

让我们看一个简单的例子。想象一下，您的组织提出了一项新计划和新设计，并从头开始创建流程以满足新的用户需求。突然之间，需要组装一个新的技术堆栈来满足这些要求。

选择无头选项将使您的产品更长寿，并使您的内容更容易顺利地进入多个交付渠道。
“

在这种情况下，您需要寻找一个完美的现成解决方案来完全满足您的需求，或者妥协一些设计和用户流程要求，以使其运行良好。但是，如果您的设计或性能要求很严格，那么通过无头来实现这些目标可能会更容易。

最重要的是，在选择无头选项时有很多用例，这将使您的产品更好地延长寿命，并使您的内容更容易顺利地进入多个交付渠道。能够将您的内容作为结构化数据使用，可以使其在您自己的网站、本地应用程序中蓬勃发展，并与外部资源联合。

并非一切都必须是无头的

听起来无头总是更好的选择，但事实并非如此。如果在您当前的项目中，您不太关心上述设计和技术选项，或者您只需要一个可以完成这项工作的运营网站，那么您可能不需要那么多无头。

当然，从概念到交付的速度很重要，因此，在没有适当的工程支持的情况下，您只需点击几下即可获得一个外观不错的网站，您可能希望将无头选项推迟到以后。一旦你觉得你的想法可能奏效，你就可以专注于网站优化和长寿。

无头选择如何帮助您从失误中恢复过来

升级后端

按用户定价的风险

不久前，我帮助建立了一个可供数十位作者使用的博客系统。无头 CMS 供应商之一的功能集给我们留下了深刻的印象，选择它作为无头 CMS 并享受在其之上构建的前端，该前端顺利融合到我们的产品套件中。最终，该公司决定将作者人数扩大到几千人。

大多数托管 CMS 解决方案不会针对这么大的用户数量发布定价结构。当我们询问在同一平台上继续运行它的成本时，我们不太喜欢这个答案。为了让这个系统继续具有商业意义，我们不得不更换我们的 CMS。由于无头架构，我们能够在不报废前端的情况下进行交换。

API 节流

如此多的专注于创作环境的初创公司能够使用开发人员友好的 API 构建漂亮的产品。 Airtable 是电子表格创新的一个例子，它通过用户友好的 UI 结合了通过有据可查的 API 的干净的开发人员体验。

我构建了一些有用的原型，将抓取的数据输入 Airtable，由人类专家进行编辑，然后使用他们的 API 为在主站点上运行的内容视图和在第三方站点上运行的嵌入提供支持。在设置读取系统时，我将 Airtable 数据提取到可以处理大流量负载的生产就绪系统中，这在一段时间内运行良好。

不过，我开始遇到写入数据的问题。由于每秒 5 个请求的硬性限制，呼叫失败。达到此限制会导致 30 秒的完整 API 请求锁定。我试图从分布式系统中发送数据，所以我添加了节流阀并将事物分成不同的基础。

随着系统的扩展和数据量的增长，我们已经超越了这个工具。我能够通过将基本的数据编辑功能构建到一个基于从 airtable 读取的 AWS DynamoDB 实例的系统中来解决这个问题。我们能够快速将流畅的 Airtable 创作 UI 功能换成更大规模和更低的每月 SaaS 账单。

这是无头创作工具的 API 提供的前端和后端之间的清晰分离如何让您精确定位痛点的另一个示例。

升级前端

闪亮的新框架

已经存在了一段时间的组织经常遇到需要支持建立在各种技术堆栈上的生产系统的问题。同质化工具和创新都面临着持续的压力。我是一个负责构建视图和小部件的团队的一员，这些视图和小部件将集成到基于无头 CMS 的现有产品中。我们在使用不同的轻量级前端工具快速构建原型时获得了很多乐趣。

我们举办了一场内部竞赛，看看前端团队中的哪个工程师可以根据从无头 CMS API 端点提供的内容来打造最好的前端。一个演示文稿具有最好的功能集和最小的代码占用空间，因此开发人员获得了项目并通过使用 Riot.js 构建它来交付产品。

Riot.js是一个很酷的小库，将大量功能打包成一个小尺寸。它可以帮助您编写数据驱动的单文件组件，例如 Vue.js。当这个前端的开发人员在发布 1.0 版后不久离开公司时，团队失去了唯一对该库充满热情的人。

有时，从令人兴奋的、新的、快速的发展模式到技术债务的转变会很快发生。
“

幸运的是，无头 CMS 架构的解耦特性提供了在不触及后端的情况下更改前端的灵活性。我们能够重写前端代码并根据其他项目中更常用的不同库交换更新的前端组件。

原始速度

我喜欢 Ghost 项目。我是早期订阅者，因为看到基于 Node.js 构建的类似 WordPress 的解决方案很酷。我尊重这个组织提供基于他们不断完善的开源工具的服务。当我将它用于我的个人博客时，我对这个工具非常满意。

不过，解决方案的一个方面并不完美。我的 Ghost 托管博客上的第一个字节的时间太慢了。由于我可以通过 API 检索所有帖子内容，因此我能够在 S3 + Cloudfront 上设置我自己的静态生成前端，该前端使用了我在 Ghost 中编写的所有帖子内容，但获得第一个字节的时间更快。

无头 CMS 即服务

有许多软件即服务业务已经全力以赴。与这些供应商之一注册可以立即为您提供友好的内容编辑环境和干净的 API 端点以供使用。以下是其中一些的快速比较，它们都有非常低成本的入门级计划，并且非常关注无头 CMS 体验。

所有这些服务都有一套坚实的基础功能。它们都包括静态资产托管、保存的修订历史记录和有据可查的本地化支持。它们在内容创建用户界面和 API 功能方面有所不同。

小贩	内容编辑	API
黄油CMS	带有 Word 样式的 WYSIWIG 编辑器的表单，带有切换到 HTML 代码的功能。您可以通过链接前端模板 URL 来配置一键式完整预览。	REST API 预览显示在与内容编辑器相同的屏幕上叠加可用的完整 JSON。
自在	基于表单的编辑器；没有看到如何设置 1-click-in-context-preview。	REST API 端点链接在编辑器模式下可用，GraphQL 即将推出。
宇宙	带有 Word 样式的 WYSIWIG 编辑器的表单，带有切换到 HTML 代码的功能。您可以配置自己的预览 URL 以提取草稿 JSON。	REST API。可以从对象编辑器中单击 2 次查看完整的 JSON。
数据管理系统	基于表单的编辑器，可以设置一个插件来启用整页预览。	带有 API 浏览器的 GraphQL API。
故事块	基于表单的编辑器，可视化编辑模式，带有全页预览。	REST API，从编辑器模式一键获取完整 JSON。
成形	基于表单的编辑器，具有可通过上传模板进行配置的实时预览。	带有 API 浏览器的 GraphQL API。

令人兴奋的无头模式

使用基于 GitHub 的 CMS

能够利用 GitHub 中的用户管理、版本控制和批准工作流程是一大优势。 不必在新系统上设置新帐户很有帮助。能够在内容更新旁边看到评论的历史是很好的。

有不同风格的基于 GitHub 的 CMS 工具。这是启动文档站点的一种快速方法：Spacebook，您可以将其与 Netlify 集成以获得更清晰的降价编辑 UI 或直接在 GitHub 上使用。

现在内置在 GitHub Web 编辑器中的预览功能使不熟悉 HTML 的人更容易使用其中的一些工具。我喜欢 GitHub 以完整预览模式显示降价更改的视图丰富的差异选项。

这是 85 个 CMS 工具的优秀列表，可让您对它们是否基于 GitHub 进行排序。

熟悉工具的 API

您的WordPress 安装附带 API 端点，因此您可以继续以无头方式使用您的团队所拥有的创作工具。 WordPress 为他们的 REST API 提供了很好的文档。这在新的 WordPress 安装中启用，因此当您启动新的 WordPress 创作环境时，您可以开始从https://example.com/wp-json/wp/v2/posts读取 JSON。

WordPress 设置页面包含一个更新服务字段，您可以在其中输入您希望它在内容更改时 ping 的服务的 URL。这非常适合触发无服务器工具以获取最新更新。 WordPress v5 在设置的写作部分有这个字段

使用 WordPress，您可以调整“更新服务”字段，您可以在其中输入您希望它在内容更改时 ping 的服务的 URL。（大预览）

组合数据源

在加利福尼亚州使用无头工具帮助我们构建了提高性能标准的应急响应站点。我们完全控制了前端架构，并且仍然能够让作者使用熟悉的创作工具。

我们无头使用 WordPress ，通过 FAAS 写入 GitHub。我们还将其他数据源写入存储库，并在每次更改时触发静态站点生成器构建。除了原始编辑内容之外，写入 git 的数据示例是每天仅更改一次的数据，例如 topline 统计数据和我们每个页面的人工翻译版本。

使用GitHub 操作作为构建触发器，我们可以将多个不同的数据源集成到站点中，从而实现快速发布和较小的生产基础架构占用空间。当我们遇到与政府大流行公告相关的流量高峰时，更少的生产基础设施让我们可以轻松呼吸。

架构的 WordPress -> FAAS -> GitHub repo 部分由 Carter Medlin 创建。在我们设计和构建站点前端的几天内，他从头开始将这条管道连接在一起。这是在无服务器 MS Azure 功能上运行的，因此基础架构成本和维护成本低。它从前面描述的 WordPress 更新服务获取 ping，从 WordPress API 中提取 json 并将新内容写入 GitHub。此无服务器端点的代码可在 GitHub 上查看。

Out 机器人在收到来自 WordPress 的 ping 信息时，会努力发布所有内容更新。此活动创建每个更新的易于查看的日志，并能够使用通常的 GitHub 流程恢复更改。

使用 11ty 静态站点生成器构建该站点的前端非常快速、有趣且运行良好。当并发用户数量开始增加并且我们发布大量内容更新时，我们会在与大流行相关的新闻中获得大量流量峰值，并且知道我们有一个静态前端可以降低风险。

我喜欢 11ty 社区通过其社区排行榜和轻量级架构关注性能和可访问性的方式。确保州政府构建的工具适用于所有加州人非常重要。我们希望事情可以在低带宽条件下在任何设备上运行，并支持所有辅助技术。我们可以使用 11ty 之类的工具让交付快速、可访问的网站变得更加容易，这真是太酷了。我们在前端使用 Web 组件来提供附加功能，同时保持代码量较小。

在 Covid19.ca.gov 上，我们可以使用 11ty 之类的工具，这些工具可以更轻松地提供快速、可访问的网站。（大预览）

做出无头选择时的注意事项

对无头工具为您的团队提供的功能感到兴奋吗？可用选项的数量可能是压倒性的。这是可以帮助您减少选项的功能列表：

创作环境功能

易于编写文档
易于添加结构化数据
布局选项
预览功能
内容审批工作流程

内容 API 功能

有哪些查询可用
内容结构的粒度如何
数据访问是否有任何限制（Airtable REST API 硬限制）
可扩展性：是否需要在内容 API 前面放置 CDN
易于添加本地化
获取您的内容，如果您改变您的计划，提取所有数据会有多难？

成本

您是否为托管解决方案按用户付费？
您是否正在管理您在自己的环境中安装的开源软件？
用户帐户是否易于管理？
您可以与现有的单点登录解决方案集成吗？
产品是否通过了安全审核，是否包括双重身份验证？

源代码控制/批准流程

内容是否版本化，以便您可以回滚到以前的版本并跟踪发布的内容以及何时进行了哪些编辑？
您可以在发布之前分享新版本的内容吗？您可以限制对这些预览的访问吗？

静态文件管理

您的作者添加新图像、pdf 等文件有多容易？
将作者上传的文件挂接到图像优化流程中是否容易？

无头的地方

当您仔细研究无头环境时，您会发现无头工具有意限制其功能范围并提供集成到更大系统的方法。当系统变得更复杂时，拆分特定功能是有益的。当您使用更小、更专注的工具时，更容易做出特定选择来限制更大代码足迹的成本、安全性、维护和托管要求。

值得注意的是，无头选项通常需要自己编写一些代码。然而，随着前端越来越多地是一组预先构建的组件，并且通常是一个完整的现成设计，其中填充了您自己的数据，期望更多的方法来混合和匹配专业工具并无缝集成不应该太冒昧无需自己编写代码的无头选项。

一个项目的完美后端可能只是一个 SAAS 订阅或一个开源项目安装。这可以无代码地与满足您所有需求的现成前端集成。我看到 Stackbit 已经将无头 CMS 与他们的无代码前端融合在一起。我可以使用 Stackbit 的 WYSIWYG 无代码页创建工具设置一个新站点，然后我可以从不同供应商的一组无头 CMS 选项中进行选择，以管理完整的站点数据。

在本文中，我们讨论了一些使用无头模式帮助我工作过的公司应对变化的用例。无论您是出于应用程序架构的灵活性、用户体验控制还是仔细考虑服务的寿命，无头选择都很诱人。

我很高兴看到这个空间如何继续增长，并将继续寻找使用这些选项的方法来提供更好的产品，并使我作为开发人员的工作更轻松。