🍂开源无头CMS评测：Strapi、Directus和Payload

在为即将推出的博客作品集考察了十几个无头内容管理系统（headless CMS）之后，我最终将选择范围缩小到Strapi v4、Directus v9和Payload v1。本文将对这三个无头 CMS 进行比较，以找出最合适的解决方案。如果您想知道我最初为什么选择这些无头 CMS，可以参考我之前的文章《如何为作品集和博客选择无头 CMS？》，其中详细介绍了我的初步研究过程。

Strapi、Directus 和 Payload，哪个才是最好的无头 CMS？为了做出最终决定，让我们分析一下这些解决方案的以下几个方面。

1. 可定制性
2. 安全
3. 开发者经验

可定制性

请记住，这三个 CMS 都是开源的，采用宽松的许可协议，因此您可以自行修改代码库。所以，理论上来说，它们的自定义程度是无限的。以 Payload 为例，它是一个配置即代码的CMS，因此其管理界面默认是空白的。考虑到这些因素，让我们来比较一下各个 CMS 官方支持的功能。

可用插件

• 获胜者：斯特拉皮

Strapi 的一大优势在于其成熟的市场。用户可以通过管理界面或访问 market.strapi.io 网站来使用市场。如果您需要其他功能，很可能已经有相应的插件可供使用。不过，Strapi 目前不支持一键安装，安装过程需要手动完成npm。

• 抽签：Directus 和 Payload

尽管 Directus 和 Payload 的模块化架构都支持插件/扩展，但它们都没有自己的应用市场。Directus 目前有一个扩展市场，但仍在开发中。您可以访问directus.market查看详情。

与此同时，有效载荷市场可能不会很快上线，但它已列入开发计划。

我们很快就会在网站上维护一份官方和社区 Payload 插件的列表。

• 来自 Payload 插件文档

数据库

• 获奖者：Directus

Directus 支持多种 SQL 版本：PostgreSQL、MySQL、SQLite、OracleDB、CockroachDB、MariaDB 和 MS-SQL。您可以将 Directus 作为现有数据库的封装层，也可以使用 Directus 从零开始构建一个全新的数据库。从某种意义上说，Directus 是数据库的抽象层（类似于 ORM，但带有用户界面），而无头 CMS 只是其众多应用场景之一。这种数据库自省特性赋予了您在使用 Directus 进行迁移时极大的灵活性，无论是迁移到现有数据库还是迁移到外部数据库。

• 第二名：斯特拉皮

目前，Strapi v4 支持 SQLite、PostgreSQL、MySQL 和 MariaDB。然而，在不同数据库和环境之间进行迁移相当繁琐。根据我的研究，这归根结底是 Strapi 和 Directus 的开发理念不同造成的。Strapi 采用“闭源”的源代码控制方式（数据库生成方式是预先设定的，开发者无法控制），而 Directus 则是一个以数据库为先的平台。如果您有解决 Strapi 迁移问题的经验，请在下方评论区留言。如果能从技术角度解释一下为什么迁移和备份一直是 Strapi 的缺点，那就太好了。

• 可疑：有效载荷

目前 Payload 仅支持 MongoDB。根据您的具体使用场景，这可能是优势也可能是劣势。由于 Payload 是市场上的新成员，相关文档和案例研究不足，因此我无法对其数据库方面做出结论。Payload v1（生产就绪版）已于 2022 年 7 月 19 日发布。

安全

安全是一个高度专业化的话题，所以我不会从技术层面比较哪种解决方案更安全。相反，我们来看看它们都提供了哪些安全功能。

授权（访问控制）

• 抽签：Directus 和 Payload

Directus 和 Payload 都提供了非常出色的安全控制，在我看来至少比 Strapi 高一个级别。它们拥有无限细粒度的基于角色的访问控制，甚至可以细化到数据库字段级别。API 和管理面板功能的访问权限均可配置。

不过，我认为 Payload 在这方面略胜一筹，因为它允许更广泛的配置。如果说 Directus 允许你使用基于角色的访问控制来限制用户的权限，那么在 Payload 中，你甚至可以从对象的角度设置权限。例如：

在 Directus 中，如果您拥有编辑角色，则可以阅读草稿状态的文章（字段条件）：if user.role == editor => read draft article

在 Payload 中，每篇草稿文章（字段条件）只有具有编辑角色的用户才能阅读。if article.status == draft => allow editor role to read这与 Directus 示例中的权限相同，只是视角不同。

• 第二名：斯特拉皮

与其他两种方案不同，Strapi 仅提供 API 级别的访问控制，因此粒度较粗。这是一方面，另一方面，Strapi 还将管理员面板角色的添加和修改设置了付费墙。对于 CMS 系统如此重要的功能来说，受到这样的限制，在我看来是一个巨大的缺点。

验证

• 获胜者：有效载荷

Payload 支持双因素身份验证，并支持多种身份验证策略，例如 OAuth 2 和 LDAP，适用于管理面板和前端应用程序。这得益于 Payloadpassport.js底层使用的是一个非常流行的身份验证库，该库支持超过 500 种身份验证策略。需要注意的是，此功能仅在 Payload v1 版本中引入，并且相关文档较少，因此如果您要构建大型项目，这可能是一个缺点。

• 绘制：Directus 和 Strapi

在后台管理面板认证方面，Directus 与 Payload 基本持平，但显然没有明确的公开用户注册实现方式。同时，Strapi 默认不支持双因素认证或其他任何后台管理面板认证策略。Strapi 的单点登录是一项付费功能，仅在黄金套餐中提供。不过，Strapi 提供与众多身份提供商的前端认证。例如，如果用户想要在您的电商网站上注册账户，则认证流程如下所示。

1. 用户通过 Google（或其他身份提供商）登录到单页应用程序。
2. Google 会验证身份并向单页应用程序返回访问令牌。
3. 该单页应用程序向 Strapi API 发出请求，并将 Google 访问令牌作为有效负载。
4. Strapi 根据提供的信息创建最终用户帐户（假设您已事先在 Strapi 中配置了身份提供程序）。
5. 您刚刚使用 Google 登录完成了新终端用户帐户的注册。

话虽如此，Directus 和 Strapi 的实战经验远比 Payload 丰富。仅凭这一点，就足以证明 Directus 和 Strapi 比 Payload 更胜一筹。毕竟，安全性一直是软件开发中至关重要的方面，但我这次还是会选择信任 Payload。

开发者经验

与可定制性和安全性不同，开发者体验很难进行客观评价。毕竟，体验大多是主观的。因此，在这方面没有明显的赢家，以下比较纯粹是我在测试这三款CMS时的个人主观感受。

管理员界面

这三款框架中，Directus 的功能最为丰富，开箱即用。如果您是无代码开发者，那么 Directus 无疑是基于 Vue 的一个绝佳选择。它甚至在管理面板中提供了专门的用户指南页面。不过，如果您更倾向于 React 生态系统，Strapi 仍然是一个不错的选择。

两者之间，我更喜欢Directus的后台管理界面。Strapi似乎想在美观上吸引非技术用户，但却因此导致界面留白过多、功能不足，这一点让我不太满意。

另一方面，Payload 在这里有点特殊。这个 CMS 的本质是代码优先，所以从某种意义上说，它对新手不太友好。Payload 管理面板主要用于输入内容（例如博客文章内容），而其他设置，例如权限、Webhook、字段定义等等，都是在代码库中定义的。我想，你要么喜欢这种方式，要么不喜欢，没有中间地带。

文档

这方面没什么好讨论的。Strapi 目前是第 4 版，Directus 是第 9 版。虽然有人认为它们的文档相比之前的版本有所退步，但它们仍然是成熟的项目，拥有大量的社区资源。而 Payload 几天前才首次发布，因此与另外两个解决方案相比，其资源和文档明显不足。

可维护性（升级、迁移、备份、部署）

这在“可定制性/数据库”部分有简要讨论。根据我的研究，普遍认为 Strapi 的可维护性很差。这是为什么呢？我并不确定。如果您能在下方评论区帮我解答这个问题，那就太好了。相比之下，Directus 的维护似乎非常轻松，因为它只是对 SQL 数据库的一个封装。您可以执行数据库级别的操作，也可以使用 Directus SDK 的功能来辅助维护。

不过，Strapi 和 Directus 都是无代码解决方案，通过用户界面配置所有内容可能会在日后造成一致性问题。而 Payload 则采用代码即配置的方式，因此可以在 CI/CD 流水线中对所有操作进行精细控制。由于大多数设置和模式都已在代码库中定义，因此也减少了处理数据库底层操作的麻烦。

主机

默认情况下，Strapi 和 Directus 都需要独立的 Node.js 实例，因此您无法将它们与您的应用程序托管在同一服务器上。Strapi 和 Directus 都是完全独立的应用程序。不过，我认为通过使用反向代理进行更高级的服务器配置应该可以实现这一点。两者相比，Strapi 的部署应该更容易，无论是简单的虚拟机、Docker 实例还是其他形式。这是因为 Strapi 非常流行，许多托管服务提供商都为其提供了一键式设置选项。

Payload 与此不同，它更像是现有应用程序的一个插件。简而言之，你的 Node.js 文件现在同时包含了前端和作为后端的 Payload。也就是说，如果你想要完全的关注点分离，我认为仍然可以将它们分开托管。

结论

Strapi、Directus 和 Payload，哪个更适合我搭建博客作品集？综合考虑这三款方案的可定制性、安全性和开发者体验，我认为 Directus 理所当然地更胜一筹。然而，这次我决定给 Payload 一个机会。总体而言，Payload 的功能与 Directus 不相上下，但它以代码为先的理念让我很想尝试一下。作为市场上的新秀，Payload 近期才发布了稳定版本，因此它可能存在一定的风险，但我愿意承担这个风险。

本文旨在记录我对当前无头CMS市场的研究。作为一名新手，我还有很多东西需要学习，因此我特意略过了性能、可扩展性、极端情况等技术对比。如果您正在为大型项目寻找解决方案，希望本文能为您提供一个良好的起点。

本文最初发表于Strapi vs Directus vs Payload，无头 CMS 对比。

对软件开发及其他相关内容感兴趣？我的其他文章或许对您有所帮助！

• 高级 GitHub Actions - 条件工作流❓
• 如何为您的博客作品集选择最佳的无头CMS？
• 使用自由开源软件来提升安全性和隐私性，这是一种谬论吗？

更多开发者新闻请访问The Dev Report，更多技术文章请访问我的博客。

另外，我们来联系吧！

• 推特：@hunghvu_dev
• LinkedIn @hunghvu
• 哈希节点：@hunghvu
• 开发者：@hunghvu
• GitHub：@hunghvu
• HackerNoon：@hungvu
• Medium：@hunghvu_dev