如何选择无头 CMS
已发表: 2022-03-10这篇文章得到了我们亲爱的 Storyblok 朋友的大力支持，Storyblok 是一个友好的无头 CMS，具有可视化编辑器、嵌套组件以及用于网站和应用程序的可自定义内容块。 谢谢！
网页（例如您现在正在阅读的网页）包含文本、图像、视频和其他资产，可以为您带来信息。 该数据将由内容编辑器在 Web 内容管理系统 (WCMS) 中进行整理和创作。 WCMS 经历了从传统 CMS 到解耦 CMS 再到无头 CMS 的演变。
迁移到无头 CMS 不是一个容易的决定，选择过程不应掉以轻心。 在本文中，我将重点介绍每个无头 CMS 应提供的一些核心功能。 我们将探索这些功能、相关挑战并帮助您选择无头 CMS 以满足您组织的独特需求。
作为 Luminary 的技术总监，我一直在帮助我们的客户选择最适合他们需求的 CMS、DXP（数字体验平台）或无头 CMS。 凭借 Luminary 在数字领域 21 年的经验、我在 CMS 领域 17 年的经验以及我们自 2016 年以来对 Headless 的关注，以下是我的两分钱，告诉你应该注意什么。
选择无头 CMS 时要考虑的事项
- 概念
- 微服务架构
- 全渠道
- 对于内容作者
- 编辑经历
- 管理图像
- 创作角色
- 工作流程
- 预览内容
- 本地化内容
- 对于开发人员
- RESTful 和 GraphQL API
- 原生 SDK
- 环境
- CDN
- 使用限制
- 其他因素
- 数据中心位置
- 技术和销售支持
- 企业功能
- 基础设施集成
- 知名SaaS供应商
- 将无头 CMS 集成为微服务
- 最佳品种服务
- 您要定位的频道
- 良好的内容建模实践
- 创作经历
- 内容项的结构
- 易于搜索内容
- 过度使用所见即所得编辑器
- 重用内容
- 组织图像
- 通过 CDN 裁剪和交付图像
- 外部最佳视频服务
- 不同的角色
- 后台用户数
- 强大的工作流程
- 网络挂钩
- 预览供应商提供的 API
- 在您的端单独的登台和生产环境
- 国际化和本地化支持
- 创建自己的处理语言环境的蓝图
- 成熟的 REST API
- GraphQL 支持
- 预览和保护 API
- 用于 CRUD 操作的内容管理 API
- 免费试用
- 支持的 SDK，供您选择技术、语言和平台。
- 无头 CMS 中的环境
- 在环境之间移植内容的能力
- 通过 CDN 缓存图像和内容
- 自定义域功能
- 某些功能的限制
- 运营开支
- 存储数据的法律和法规要求
- 本地销售和技术支持
- 离不开的企业功能
- 与供应商和产品的社区参与
- 支持您选择的基础架构
- 去无头：用例和它的好处
- 不要失去理智：评估无头
单体与微服务
我们已经在 Smashing Magazine 上详细探讨了无头 CMS 背后的概念，但让我们快速回顾一下。 对于传统的 CMS，CMS 和由此产生的前端网站是建立在一个整体架构上的。 传统 CMS 以多种方式尝试并成功地满足了开发人员、内容作者和营销人员的需求。 例如，如果 CMS 是基于 Microsoft 的 .NET Framework 构建的，那么前端网站也将基于相同的技术构建。 所有功能和集成也将具有紧密的依赖关系，这反过来会导致庞大、繁琐的单体代码库。
解耦的 CMS在一定程度上消除了这种相互依赖。 这是通过将前端网站与 CMS 后台和内容存储库分开来实现的。
单体架构在无头 CMS 中处于次要地位。 CMS 和所有其他集成都是微服务。 CMS 本身是基于软件即服务(SaaS) 模型提供的，我喜欢将其称为内容即服务(CaaS)。 使用这种微服务架构，您从传统 CMS 中获得的一切都不会凭空出现。 您可能有不同的服务和供应商来为您提供满足您的每个要求的最佳品种。
转向微服务思维需要一点耐心。 我们有来自传统 CMS 背景的营销人员，他们拒绝在使用无头 CMS 时深入研究多个系统和服务的想法。 在选择和实施他们的无头 CMS 平台期间，我们设法带他们一起踏上了旅程。 现在，他们是无头 CMS 平台的拥护者，因为它允许他们集成新系统和服务，而不是绑定到传统 CMS 提供的系统和服务。
密切注意，提防，小心：
全渠道为核心
在集成无头 CMS 时，尽管微服务思维方式可以帮助您，但无头的真正力量是在其全渠道性质中实现的。 全渠道体验以您的客户为中心，并通过统一销售和营销在您的品牌中创建单一客户体验。 借助无头 CMS，可以将内容提供给不同的渠道，例如网络、移动、社交、无 UI 智能设备、物联网设备，甚至是实体店面等非数字接触点。
使用无头 CMS，您需要从头开始为每个内容模型定义模式。 为您创建和发布的内容项定义这种健全的逻辑分类结构的过程称为内容建模。 如果您的第一个渠道将成为您的网站，请确保您的内容建模将全渠道考虑在内，以减轻未来的痛苦。 如果您只是在寻找替代 CMS 来为您的网站提供动力，请再仔细研究一下传统或解耦 CMS 空间，看看是否有更适合您要求的东西。
在对内容模式进行建模时，请考虑未来。 甚至不到十年前，我还在一家大型航空公司工作，我记得曾尝试为移动设备建模内容（是的！移动网站有一个单独的子域）。 这是极其困难的，因为内容模式仅适用于桌面网站。 但即使在今天，我们也需要对内容建模保持警惕。
密切注意，提防，小心：
创造伟大的内容
无论是传统的 CMS 还是无头 CMS，主要需求是管理内容。 内容作者应该喜欢在后台工作。 如果您看到作者转向其他创作工具（例如 Google Docs）以获得评论或建议功能，则可能是您缺少哪些功能的危险信号。
与内容作者合作时，Microsoft Word 文档、电子表格、Google 文档总是会抬起头来。 让内容作者在 CMS 上工作的最简单方法是为他们提供所需的功能，然后他们会自动逐步淘汰这些功能，而不是试图提前驱逐他们。 当我们将 Luminary 自己的网站推送到无头 CMS 上时，每个团队成员（其中 50 人）都有足够的访问权限来添加和编辑他们自己的网站个人资料。 在没有 50 个 Google Docs 到处乱飞的情况下，它奏效了。
编辑经验
使用无头 CMS 的决定可能是 IT 决定。 但组织内营销人员和内容作者的支持对于其采用和成功至关重要。 允许内容作者轻松输入内容、查找现有内容和重用内容的无头 CMS 应该是开箱即用的东西。
为了便于创作内容，必须拥有易于使用的编辑器，例如所见即所得编辑器、文本编辑器、下拉菜单和自定义编辑器。 一个干净和简约的界面，允许内容作者专注于手头的任务，将受到赞赏。 允许在同一界面中同时编辑、评论和创建子内容项的编辑界面将提高内容作者的生产力。
使用 WYSIWYG 编辑器或严重依赖任何生成 HTML 的编辑界面时请注意。 由于无头 CMS 旨在迎合多个渠道，因此依赖所见即所得的编辑器将消除可重复使用的内容的原子性质。 确保自定义编辑器允许在粒度级别访问数据字段。 我们已经看到这阻碍了跨不同渠道（例如移动和桌面）的内容重用。
对于无头 CMS，以树状结构组织内容项不是常态。 但它是一座桥梁，让内容作者可以轻松地从传统 CMS 过渡到无头 CMS。 如果内容项没有以树状结构可视化，那么具有分面和标记功能的强大搜索引擎对于您的内容编辑器来说至关重要。 这使作者可以轻松地查找和重用现有内容。
在重用内容时，要考虑的另一个方面是内容项是否可以轻松地嵌套在其他内容项中。 这允许最大程度地重用现有内容。 但要注意对内容的循环引用，这可能会导致头痛和性能问题。 一个示例是律师的内容项，该内容项链接到专业知识的内容项。 然后，如果专业知识内容项再次链接到多个律师内容项，则这可以形成循环引用。 寻找具有智能功能的无头 CMS，以限制 API 和可视化的深度，以显示链接的内容项，以避免这种陷阱。
密切注意，提防，小心：
图片的价值：如何处理媒体
一张图片胜过千言万语。 但是图像资产难以运输、难以组织且难以搜索。 在典型的 CMS 中，随着时间的推移，您会看到重复和名称不佳的图像资产。 重要的是，为内容编辑器提供工具来组织、分类、标记、重用和搜索无头 CMS 中的图像。 对我来说，这意味着在文件夹或容器中组织资产。 但是最好了解您的团队在管理静态资产方面的要求。
上传单个图像，为其设置焦点，然后针对不同设备和屏幕尺寸操纵其尺寸和质量的能力，为内容编辑器甚至那些在幕后工作的设计师/图形艺术家节省了大量时间。 通过内容交付网络 (CDN) 以 WebP 等格式交付静态资产对于为用户提供快速网站也至关重要。
大多数无头 CMS 都带有这些开箱即用的功能。 如果没有，您需要决定可以不使用哪些功能。 该规则有一个警告。 对于原始图像的广泛编辑，您应该坚持使用最适合该工作的工具，例如 Photoshop。
除图像外，下一个最重的资产是视频。 再一次，以微服务的心态，视频流应该留给服务提供商，如 YouTube、Vimeo 和其他在线流媒体服务。 如果您的无头 CMS 可以为您提供一个不错的编辑界面来搜索或从这些提供商之一中选择视频，那将是一个额外的好处。
密切注意，提防，小心：
创作角色
谁可以输入内容，谁可以批准或发布内容到实时站点，以及其他细粒度的权限也需要通过无头 CMS 进行管理。 一个两人团队可以在没有不同创作角色的情况下生存，但随着组织和内容团队的发展，创作角色是必须的。
我曾与 40 多名编辑的内容团队合作，需要根据您选择的无头 CMS 仔细评估此要求。 否则，混乱将占上风。 在与我共事的 40 人团队中，我们有文案撰写人、翻译人员、QA 人员和法律审批人员，他们拥有不同的权限来访问某些内容、语言变体、工作流程审批和发布权。
不同角色和后台用户的数量通常是无头 CMS 定价的方式。 在比较供应商之间的价格点时，请考虑当前数字和内容团队的未来增长。
密切注意，提防，小心：
工作流程
并非每个内容项都需要通过工作流进行管理。 但是，当需要工作流、审计跟踪和批准时，需要在无头 CMS 中管理流程。 在无头 CMS 上从头开始构建强大的工作流程，让您高枕无忧，并有机会根据您的业务流程处理每个内容项。 通过 webhook 或 API 集成第三方系统的能力是您应该注意的一个好处。
密切注意，提防，小心：
内容预览
内容编辑器已创作内容、添加图像并通过工作流发送以供批准。 但是，在将内容提供给公众之前，他们在哪里预览内容呢？ 这就是用于检索未发布内容的预览 API 和设置预览环境的能力发挥作用的地方。
有了无头 CMS，摆脱了单一渠道的思维方式，您的内容编辑不应该期望在 CMS 后台看到全页预览。 每个频道都应该有自己的登台或预览环境来查看尚未发布的草稿内容。 这可能是您网站的临时站点或本地安装的移动应用程序版本。 您为所选的无头 CMS 选择的定价计划中必须提供预览功能。
密切注意，提防，小心：
语言环境
如果您的内容需要提供给不同的语言环境，则需要在项目早期确定该要求。 改造是可能的，但不是一个有趣的活动。 应该考虑并记录您如何管理跨文化和语言的内容和资产。 我建议创建一个蓝图来确定哪些语言和资产从另一个继承或默认。 然后确保您选择的无头 CMS 支持该蓝图或探索以不同方式实现相同结果的途径。
密切注意，提防，小心：
创造伟大的内容总是很重要的。 因此，内容作者应该在他们的日常活动中获得最佳体验，以使您成功过渡到无头 CMS。
“
开发时间很宝贵
对于无头 CMS，开发人员的参与是必须的。 这可能是后端开发人员或前端开发人员使用无头 API 在网站上显示内容。 但是一旦完成初始开发，内容作者应该能够以最少的干预工作。 这就是使用 CMS 的全部意义所在。 它也适用于无头 CMS。
在比较功能时尽可能多地考虑内容作者，开发者功能也应该被探索。 在本节中，我们将介绍可以为开发人员节省时间的功能。
API/GraphQL 支持
允许内容项的选择、分页和投影的成熟 API 对于开发人员使用无头 CMS 至关重要。 开箱即用的 GraphQL 支持是另一个决定性因素，因为它将允许开发人员在非常精细的级别上定义他们需要的结果。 全面的文档和代码示例也是必须的。
在提交无头 CMS 之前，请确保您的开发人员对内容检索 API 感到满意。 不要忘记预览 API、安全 API 以及通过代码轻松使用它们。 您想自动化内容创建吗？ 然后应该考虑内容管理 API 。
内容管理 API 一直是我们的福音，我们将 2,000 多篇博客文章从 WordPress 站点自动导入到无头 CMS。 所有博客文章和相关图像都是以内容作者的最少工作量导入的。 一些无头 CMS 提供了 Google 表格插件和其他漂亮的工具，只需单击一下按钮即可完成此操作。
由于许多无头 CMS 提供免费试用，因此最好让它们进行试驾，以了解它们对您选择的内容创建和检索的适用性和一致性。
密切注意，提防，小心：
原生 SDK
适用于各种技术、语言和平台的软件开发工具包 (SDK) 可直接从 Headless 供应商、开源计划或第三方处获得。 确保这些 SDK 支持您将在其上构建网站或消费者应用程序的技术、语言和平台。 尽管 RESTful 和 GraphQL API 允许您查询内容，但拥有原生 SDK 可以显着减少开发时间。
在 Luminary，使用用于无头 CMS 的原生 SDK 使我们能够采用 Microsoft .NET Core 和 .NET 5 等最新技术。此外，在现有 SDK 的基础上构建使我们能够遵循供应商推荐的最佳实践，同时节省成本时间。
密切注意，提防，小心：
环境
夫妻店的网站或应用程序可能能够通过单一的生产环境来策划和预览内容。 但随着组织、团队和功能的发展，需要多种环境来管理和预览内容。 您的无头 CMS 不仅需要提供环境，而且您的消费应用程序也应该设置环境。 需要考虑跨环境刷新内容的方法。
密切注意，提防，小心：
图像、文件和 CDN
在讨论内容作者的功能时，我们谈到了管理图像。 从开发人员的角度来看，不仅静态资产需要缓存在 CDN 上。 许多无头 CMS 缓存通过 RESTful 或 GraphQL API 检索的内容。 这加快了检索过程并为您的应用程序带来了性能改进。
虽然 CDN 缓存非常有用，但有时缓存损坏或较旧的缓存项目可能会产生问题。 清除 CDN 缓存或提取具有特定 HTTP 标头的最新内容的能力应该是无头 CMS API 功能的一部分。
对 CDN 使用自定义域来交付内容或静态资产的能力可能是您需要考虑的一项要求。
密切注意，提防，小心：
跨计划的使用限制
要考虑的另一个因素是为您订阅的每个计划设置的使用限制，这些计划是针对您选择的无头 CMS 的。 需要考虑内容项的数量、带宽消耗、后台用户的数量、API 调用的数量和速率限制。 在规划使用限制时，请考虑当前使用和未来使用。 请记住，许多无头 CMS 在订阅的基础上运行，它们确实允许您几乎立即升级到具有更高限制的计划。
但是，值得了解有多少用户将使用该平台，以及该解决方案是否需要大规模扩展。 我们目睹了一个客户收到一笔非常大的账单，因为他们在不知不觉中添加了大量用户，超出了分配的配额。 管理员最好了解他们的 Headless 计划提供的内容并密切关注使用情况。
请考虑使用客户端缓存、静态页面生成器和智能 API 或 GraphQL 调用将当前限制保持在使用限制以下，以减少您的运营支出。
密切注意，提防，小心：
开发人员的时间很昂贵。 尽管无头 CMS 被吹捧为对开发人员友好的 CMS，但每个供应商都有各自支持的不同功能。 强烈建议您根据开发人员的需求了解和比较这些内容。
“
其他因素
还有一些其他因素可能不会影响内容作者或开发人员。 这可以从市场营销到财务，再到您所在行业和业务的法律和监管要求。
数据中心位置
我们经常被问到的一个问题是，数据存储在哪里？ 是的，在云端。 但是由于某些企业的法律和监管要求，哪个地理数据中心是一个重要的问题。 允许您将数据存储在您选择的数据中心的无头 CMS 可能是决定您选择哪种 CMS 的关键因素。
技术和销售支持
在您的时区获得技术和销售支持的能力是选择无头 CMS 时的另一个决定因素。 由于没有本地销售人员，许多项目都倾向于那些在相关地区有人员的供应商。
由于能够将数据存储在澳大利亚境内的 Azure 数据中心，我们有一个大型 NFP（非盈利）组织选择了无头 CMS 供应商。 拥有实地销售支持和全天候技术支持为该无头 CMS 供应商赢得了销售。
密切注意，提防，小心：
要考虑的企业功能
一些大型组织可能需要与公司的身份验证系统或审计日志相关联的单点登录 (SSO)，以便轻松查询。 在 SaaS 产品被认为合适之前，可能需要集成现有系统和某些 ISO 认证。 在选择无头 CMS 时，列出这些企业功能以及企业级组织独有的其他功能是一个很好的起点。
社区在行动
另一个通常被忽视的领域是围绕给定无头 CMS 的社区。 那里有对产品充满热情的人吗？ 我不是在谈论供应商的营销窥视。 使用该工具的人是否有足够的开源资源共享？ 这可能不是决定性因素，但当您在项目的实施或支持阶段处于困境时会有所帮助。
基础设施集成
使用无头 CMS，您不受技术、语言或平台的束缚。 构建无头 CMS 的技术或平台不会影响客户端应用程序。 您可以使用您选择的技术，从 .NET 到 Node.js，您的操作系统可以是 Windows、Linux 或 macOS，您的语言可以是从 Python 到 C# 的任何语言。
同样，在采购基础设施方面，您可以选择在 Netlify、Azure、GCP 或 AWS 上托管您的网站。 您的网站架构及其基础架构决策现在完全基于您的要求。 还有与 Gatsby Cloud 等服务的原生一流集成，带来更多组合，让您的生活更轻松。 对于某些人来说，这可能是一个重大决定，应该通过与 Headless 领域的一些专家从业者交谈来做出。
密切注意，提防，小心：
我们在 Luminary 的经验
在 Luminary，我们有幸与无头 CMS 合作，例如 Acoustic、Contentful、Kentico Kontent 和 Umbraco Heartcore。 自这些 CMS 平台的 beta 版本以来，我们一直在与其中一些 CMS 合作。 公共路线图、出色的技术支持以及解决我们的功能请求是我们在这些平台上的一些亮点。
我们在使用仅前端实现、缓存大型列表页面、处理大型服务器端缓存以及将其他微服务与无头 CMS 集成的无头网站处理 SEO 方面拥有丰富的经验。 其中每一个都有其独特的挑战，您应该注意这些挑战。 此外，传统 CMS 上的简单任务（例如表单提交和站点搜索）以及更高级的功能（例如用户身份验证和第三方服务授权）都需要经过深思熟虑。
如果您选择了正确的无头 CMS 和正确的实施合作伙伴，那么您最终应该得到一个无头 CMS，它会让营销人员、内容编辑和开发人员开心。