不要失去理智：评估无头
已发表: 2022-03-10这篇文章得到了我们亲爱的 Storyblok 朋友的大力支持，Storyblok 是一个友好的无头 CMS，具有可视化编辑器、嵌套组件以及用于网站和应用程序的可自定义内容块。 谢谢！
许多选择伴随着许多决定，并且很容易淹没在不同系统的所有众多和各种声明的好处中。 那么，您如何评估这些选项呢？ 两周前，Aaron Hans 在 Smashing Magazine 上阐明了无头的用例以及它的好处。 今天，我将向您介绍 CMS 领域的一些入门知识，以及一些帮助您做出决定的问题。
无头？ 什么？
无头内容管理是将内容管理系统 (CMS) 与前端分离的做法。 与传统（或“单体”）系统不同，CMS 不直接负责为 Web 前端提供动力。 相反，内容通过 API 从远程系统提供给前端，前端使用这些数据来呈现其页面。 这可能发生在运行时（当用户登陆您的网站时），也可能发生在构建时（内容被预先渲染并提前生成），但这里的重要概念是内容层和表示层之间的分离。
如果您打算使用 Jamstack 创建一个站点，那么默认情况下您最终会朝着这个方向前进，但该方法对于其他类型的项目同样有效，使用服务器端语言（如 PHP、.网，或红宝石。
但为什么这甚至是一件事？
Headless 最初是作为 Jamstack 管理内容的一种方式出现的（在 Jamstack 获得它的时髦名称之前），但由于很多原因，这种方法已经获得了粉丝。 无头内容管理允许我们将内容部署到不同的平台，例如，您可以在本机移动应用程序中使用您网站中的内容。
Headless 还允许我们修补其他系统中的缺点。 例如，Shopify。 虽然它的功能很棒，但在管理在线商店的内容时，它并不是最灵活的系统。 使用无头 CMS，我们可以远程管理 Shopify 网站的其他内容，并带来比默认情况下更多的功能和灵活性。
我最近在一个项目上做这件事——扩展 Shopify 提供的内容，使用来自无头 CMS 的更多、更丰富的内容（我们碰巧在这个特定项目中使用了 Contentful，但任何无头 CMS 都可以完成这项工作）。 使用无头内容管理解决方案使我们能够创建可以根据需要定制的自定义数据结构。 例如，客户想要突出他们在制造产品时使用的成分，而 Shopify 并没有真正提供管理这一点的好方法。 我们在 Shopify 中创建了一个新的内容类型，并允许将其添加到包含我们创建的其他类型内容的自定义产品页面。
Shopify 内容被提取并同步到 Contentful，这成为该网站的主要数据驱动程序，Shopify API 仅真正参与库存水平检查和购物篮创建。 能够将这种丰富的数据添加到基于 SaaS 的电子商务网站是非常强大的。
我们碰巧使用 Nuxt 构建站点来实现这一结果，但我们同样可以选择将来自 CMS 的数据直接集成到 Shopify 模板中。 这里选择Jamstack作为更好的方法，但 headless 足够灵活，几乎可以在任何地方使用。 只要您可以通过 JavaScript 或更传统的后端语言（如 PHP 或 .Net）访问某种脚本，您就可以将 headless 集成到您的工作流程中。
将您的内容与表示层分离可能非常强大。 允许您的内容插入到不同的平台和表示层有助于使您的内容在您的接触点之间保持一致，并有助于确保您的内容不会分散在由不同团队管理的一堆不同系统中。
想象一下，您想在您的网站、移动应用程序以及程序化广告中谈论您想要谈论的产品。 使用 headless，您可以拥有一个中央内容存储库，并将相同的内容（或内容的各个方面）部署到所有这些平台等等。 对于更传统的内容管理，您需要分别管理不同平台的内容。
这听起来很棒！ 那么无头适合我吗？
选择方法时需要考虑很多事情。 无头模式有好处，但也有代价。 在考虑将无头作为一种方法时，要问自己以下一些问题：
您对拆分的知识要求感到满意吗？
很多人认为迁移到 headless 可以“摆脱”对后端开发人员的需求，但事实是，有效构建数据和构建工作和扩展的内容模型的思维方式仍然与思维方式有很大不同大部分时间都需要成为一名出色的前端开发人员。 仍然存在知识差距，仍然需要填补。
如果您正在处理一个大规模的项目，您可能仍然希望一些开发人员专注于“后端”领域，而一些开发人员则专注于“前端”。 在无头土地上，这些部门更精细，更具可塑性，但不要误以为您可以通过无头来减少一半的开发劳动力。
您知道总拥有成本吗？
虽然无头通常可以证明比单体更便宜，但大多数这些系统的 SaaS 特性可能意味着对于大型、快速变化的数据集或非常大的团队，成本可能不会累加。 始终检查成本是如何扩展的，以及扩展的基础是什么。 一些供应商根据数据量进行扩展，一些根据 API 请求的数量，还有一些根据编辑您的内容的协作者数量。 这些因素的结合会对您的成本随规模增长的方式产生巨大影响。
您可能还需要查看多个不同的平台，以了解您的总拥有成本。 如果您没有“开箱即用”地进行搜索，则需要考虑添加该功能将花费多少。 您通常可以预测这些成本将如何扩展，并且您通常可以从小处着手，但值得了解的是，从长远来看，这些事情可能会让您付出什么代价。
如果您确实选择无头模式，请密切关注您的构建时间：这些时间会迅速增加，尤其是在开发和内容填充阶段。 请注意，如果您选择静态生成站点，则需要在 CMS 的每个发布操作后进行构建。 对于大型站点，这些构建可能需要一段时间，因此值得记住的是，这些构建需要加以检查。 许多流行的静态托管服务（例如 Netlify 和 Vercel）支持构建资产缓存，并且与支持增量构建的现代框架相结合，这可以帮助减轻这种不断增加的成本，但您仍然需要密切关注它并做好您的研究以确保您不会被抓住。
您是否为您的客户解释得足够好？
您可能喜欢使用 Jamstack 和 headless 的开发人员体验，但是在进行这些评估时，您必须记住，客户是必须使用和使用您组合的解决方案的人，因此您需要努力让他们的生活尽可能轻松。
在之前的职位中，我参与了向一家汽车制造商的宣传，该制造商表示他们希望将行业领先的性能作为首要任务，但他们最终选择了另一家提供更传统解决方案的机构。 发生这种情况的原因有很多。 （我们很可能在推销我们方法的好处方面做得不够好，但是对于内容编辑来说，无头模式似乎也很可怕，尤其是在面对一些有天赋的传统“企业”系统时让它看起来像一切“正常工作”。）
当你没有头绪时，你将把单独的工具组合在一起，每个工具都被设计为非常擅长某一特定的事情，而不是拥有一个可以在一个地方完成所有这些事情的大型系统。 除非您可以让您的客户尽可能轻松地处理，否则这可能会非常令人生畏。
您是否考虑了额外的开发时间？
headless 的所有潜在功能和灵活性都不是免费的。 一切都是定制的缺点之一是，这意味着一切都需要从头开始开发。 对于这个空间中的许多选项，没有真正的“默认”文档模式——事实上，它们是经过精心设置的，没有任何像这样的默认值。 一方面这很好，因为这意味着您可以获得与您的需求完全匹配的紧密定制的文档模型。
但是，另一方面，这意味着有人需要定义这些文档模型，然后有人需要为您正在使用的系统创建它们。 然后，由于前端和后端是解耦的，通常需要有人创建一个引擎来允许预览草稿内容； 许多现代框架包括一个允许预览草稿内容的系统，但它们通常需要额外的配置才能工作，有些需要一定级别的自定义代码。 当然，前端与内容无关，因此任何数据到前端组件的映射也需要完成。 即使使用紧密耦合的 CMS，您通常也必须至少完成其中的一些工作，但您可能必须为所有这些事情分配时间这一事实可能会很昂贵。
您/您的客户对不在您自己的基础架构上的数据感到满意吗？
虽然许多使用无头 CMS 系统和其他 SaaS 供应商的人经常认为这是积极的，但在某些情况下，您自己的基础设施之外的数据可能不太理想，例如涉及敏感产品或非公开生产数据的情况。 这些公司的安全性通常很好，但总是存在风险。
确保您权衡将内容存放在某处的匿名 AWS 服务器上的相对好处。 我们之前已经看到，即使是强大的 AWS 也可能会出现中断，对于业务关键型系统来说，这些可能会造成极大的损失。 AWS 上的 SaaS 或使用您自己的基础设施之间的区别在于，如果您自己的基础设施出现中断或安全漏洞，这很可能取决于您自己的产品或代码，但在 SaaS/AWS 环境中，中断是更有可能是由与您的业务无关的因素引起的。 这些情况很少见，但确实会发生，在做出这些决定时考虑到这一点很重要。
好，很好。 那么我的选择是什么？
2021 年可用的无头和无头内容管理解决方案的数量惊人且不断增长。 与其试图在这里涵盖所有选项，我只想简单介绍一些比较知名的选项。 如果您正在寻找更全面的列表，那么您可能需要查看 Headless CMS 或 CMS 比较。
满足的
Contentful 是最成熟的无头 CMS 选项之一，成立于 2016 年，并获得了几轮成功的种子投资，并将自己描述为“提供数字体验的 API 优先内容平台”。
近年来，Contentful 在更好地支持已翻译和跨创建的内容方面取得了长足的进步，并且它们对多种内容“环境”有很好的支持，允许从您的生产数据中进行更改并在以后进行迁移。
Contentful 有一套与其他 SaaS 应用程序的集成，因此很容易与 Shopify 或 CommerceLayer 等电子商务应用程序集成，或与 Cloudinary 等资产托管和处理应用程序集成。
最适合：
那些正在寻找无头空间中最完善的解决方案的人。
故事块
Storyblok 是这里唯一一个真正将自己描述为 CMS 的无头优先选项，并且具有非常好的可视化内容编辑器，它允许您使用奇妙的所见即所得界面创建和编辑看似在原位的内容。 这是将 CMS 与网站分离的传统弱点之一，因此看到 Storyblok 创建的这种编辑环境是向前迈出的一大步，团队应该为在这方面推动市场向前发展而感到自豪。
Storyblok 还能够使用他们的 API 生成内容模式，让这些东西与您的代码一起生活，这对可维护性很有帮助。 基于角色的权限和翻译/创译功能使分布式团队能够愉快地在多语言网站上工作。 总体而言，Storyblok 感觉像是一款经过精心设计且经过深思熟虑的产品，尤其是内容团队可能会喜欢的产品。
最适合：
那些从无头 CMS 中寻找一流的所见即所得内容编辑解决方案的人。
理智
理智是这个领域中较新的孩子之一，但很快就引起了人们的注意。 他们将自己描述为“帮助团队实现远大梦想并快速交付的终极内容平台”。
Sanity 做的事情与这里的其他选项略有不同，因为你所有的配置和内容模型都是作为代码完成的，对于开发人员来说，这是一个舒适的地方来保存东西。 通过使用文档模型和自定义字段类型允许几乎无限量的创造力，Sanity 允许开发人员为各种事物创建深度、丰富的内容结构，而不仅仅是 Web 内容。
Sanity 中的编辑套件简洁、可定制、开源，并且基于 React。 您可以将编辑工作室部署到您喜欢的任何主机，或选择使用 Sanity 子域在其基础架构上进行托管。
最适合：
那些需要绝对控制几乎所有实现方面的人，从自定义数据结构到输入组件。
棱镜
棱镜确实是无头空间房间里的老角色，早在 2013 年就已经出现了，但这并没有阻止他们在空间中的创新。 就在去年，他们推出了 SliceMachine，旨在通过在内容块（或“切片”）和前端组件之间创建 1:1 的关系来弥合创建组件的前端开发人员和内容作者之间的差距，这使得构建新的页面和内容部分对编辑来说轻而易举。
Prismic 的编辑套件很可爱，他们似乎修补了一些曾经存在于他们的字段选择中的漏洞，因此它提供了一个全面的体验。
最适合：
那些希望尽量减少内容编辑的摩擦的人。
如果我想要一些更传统的东西怎么办？
WordPress
WordPress 在 2021 年仍然很庞大。尽管围绕其他平台大肆宣传，但 WordPress 仍然为大约 40% 的互联网提供动力，而且它不会去任何地方。 开发人员正在通过改进其无头功能并更加关注其 API 支持来帮助确保这一点。 新的编辑工具也使在 WordPress 中写作的体验更加愉快，并且近年来使用 WordPress 的一些固有权衡得到了极大的改进。
与 Nestify 这样的 WordPress 即服务公司合作可以让开发人员摆脱很多焦虑和安全问题，但请注意，作为互联网上最大的平台，WordPress 仍然非常诱人针对有恶意的人。
最适合：
那些希望坚持舒适、熟悉的内容平台，同时使技术保持最新的人。
网站核心
作为企业内容管理的巨头之一，Sitecore 可能是您最不希望在此列表中看到的名称之一，但他们在支持无头，发布 Sitecore JSS 以使 Jamstack 项目能够与 Sitecore 数据交互方面取得了巨大进步。
以无头方式使用 Sitecore 或其他企业 CMS 系统的最大困难一直是启动和运行个性化，但是 Uniform 的人已经解决了这个问题，他们实际上开始使用 Sitecore 来启用这种功能.
Sitecore 是一头野兽，它不适用于很多项目——仅成本一项就超出了除企业级客户之外的所有客户的范围——但它与 AEM 一起值得在这里列出，因为仍有很多人认为无头内容管理只适用于小型网站。
最适合：
那些与不一定想“全力以赴”新技术的客户一起寻找企业项目的人。
Adobe 体验管理器
Adobe Experience Manager（或 AEM）是企业端的另一个主要参与者。 就像它的大多数竞争对手一样，它是巨大的，而且非常昂贵，但是 Adobe 是另一家做出巨大努力的供应商，以使他们的产品对那些想要将其内容与网站展示分开的人更加友好。
AEM 现在支持从其平台请求数据的几种不同方法，Adobe 现在将 AEM 推销为“混合 CMS”，这意味着它在一个引擎盖下结合了无头和更传统的、特定于渠道的操作。 对于需要跨不同平台工作并需要在这些平台之间精细控制内容的营销团队来说，这可能是一个很大的优势，但是那些想要加入 Adobe 的“一个平台来统治所有平台”的营销团队将需要雄厚的资金才能开始。
最适合：
那些着眼于企业最高端、财大气粗的人！ AEM 做了很多事情（比我们希望在这里提到的更多），但它很昂贵。
现在我对我的选择有了一个想法，但我怎么能希望在它们之间做出选择呢？
现在无头空间中有很多选择，您很容易陷入选择瘫痪。 但是，您可以使用一些问题来帮助形成初步意见或至少缩小该领域：
您需要多长时间才能加快速度？
不同的系统有不同的学习曲线和不同的支持开发者的方式。 此处列出的每个系统都有一个围绕它构建的开发者社区，但并非所有社区都是平等的。 供应商是否提供详细的文档？ 启动项目？ 所有这些都会对启动时间产生重大影响。
您需要什么样的支持模式？
支持模式通常对客户来说是最重要的，而且您经常发现要获得更直接的支持，您需要为“企业”套餐付费，这可能会使您的投资高于您对使用情况的预期。
供应商的实力如何？
供应商的知名度如何？ 他们是如何获得资金的？ 同样，这些通常是客户的考虑，而不是开发人员的考虑，但是能够尽早告诉客户您推荐的供应商是稳定的，已经存在 X 年，并且他们有足够的财务支持，这是值得的确保他们不会很快去任何地方。 任何客户想要处理的最后一件事是强制重新平台化，因为他们现有的供应商正在淘汰他们的产品，而客户正在参与他们的中途！
编辑体验是怎样的？
对于任何项目客户端的许多人来说，编辑经验可能都非常重要。 这些人将日复一日地使用您选择的任何 CMS。 如果 CMS 是一场噩梦，他们会这么说——很多。 相信我，我参加过许多推介和后续会议，在这些会议上花费了大量时间与客户一起列出他们对现有系统的许多挫败感！
“您正在查看的系统能否提供上下文编辑或实时草稿预览？”
“设置这些需要多少努力？”
“编辑器本身的运行速度有多快或多慢？”
“用户是否被选项和不熟悉的按钮轰炸，或者事情是否井井有条？”
所有这些问题都反映了系统的整体易用性。 一些解决方案，例如 Storyblok，已经竭尽全力让内容编辑成为一种丰富且无缝的体验，但它通常不被认为是整个无头景观中的强项，因此绝对值得放一个小规模的演示在您的内容编辑者面前，看看他们对您关注的解决方案的看法。
从平台上获取数据有多容易？
我已经数不清自己参加过多少次推介会议，并被告知我们可能不得不从头开始或为内容编写自定义刮板，因为客户的内容完全依赖于专有的内容管理系统，他们不能轻易地导出他们的数据。
无论您选择的 CMS 看起来多么酷，请绝对确定有一种简单的方法可以在某个时候将您的所有内容从系统中取出。 可悲的是，没有系统是永远的，客户最终会想要改变他们的网站，以及他们的基础设施。 到那时，您可以做的任何让他们的生活更轻松的事情都将是一个巨大的积极因素。
使用无头 CMS 解决方案通常更容易做到这一点，因为它们的核心是支持 API 的，但它仍然需要进行更仔细的审查，以确保您不会在几年后引起巨大的头痛。
加起来
选择内容管理的方法和平台是任何数字项目的重要选择。 无头内容管理功能强大且灵活，但确实会带来一些成本，而且并非适用于所有情况。
请注意，您预先从供应商那里看到的价格很少是解决方案的最终总成本，并确保您不会陷入认为可以通过消除传统的“后退”来降低开发成本的陷阱-end”的开发人员。
确保每个人都对使用无头 CMS 而不是更传统的设置的现实感到满意，并确保将内容编辑器带上旅程，因为他们是使用您设置的系统最多的人频繁地。
希望本指南至少有助于为炒作提供一些背景信息，并可以帮助您做出您和您的客户都可以接受的决定。 你现在可以用headless 为中心构建几乎任何你想要的东西——但总是问自己，你是否正在寻求一个解决方案，因为它是熟悉的或被炒作的，或者它是否真的是适合你情况的最佳解决方案。