在为我即将发布的博客作品集查看了十几个无头内容管理系统(无头 CMS)之后,我将选择范围缩小到只有 Strapi v4、Directus v9 和 Payload v1。本文介绍了三种无头 CMS 之间的比较,以找出最合适的解决方案。如果您想知道我为什么首先选择这些无头 CMS,我之前的文章如何为投资组合和博客选择无头 CMS?是我最初研究的演练。

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

1. 可定制性

2. 安全

3. 开发者经验

可定制性

请记住,所有三个 CMS 在许可许可下都是开源的,因此您可以自行修改代码库。因此,可定制性在技术上是无穷无尽的。对于 Payload,它是一个 configuration-as-code CMS,因此它的管理 UI 实际上是开箱即用的空白。考虑到这些,让我们尝试比较一下 CMS 官方支持的内容。

可用插件

• 获胜者:Strapi

Strapi 的一大优势是其成熟的市场。它可以通过管理界面或网站market.strapi.io访问。如果您需要附加功能,很有可能它已经作为插件提供。也就是说,没有一键安装功能,只能通过npm安装。

• 绘制:Directus 和 Payload

尽管 Directus 和 Payload 在其模块化架构中都支持插件/扩展,但它们都没有市场。关于 Directus,有一个扩展市场,但仍在开发中。您可以在directus.market查看。

与此同时,Payload 市场可能不会很快推出,但它在路线图上。

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

*来自 Payload 插件文档

数据库

• 获胜者:直接

Directus 支持多种不同风格的 SQL:PostgreSQL、MySQL、SQLite、OracleDB、CockroachDB、MariaDB 和 MS-SQL。您可以使用 Directus 作为现有数据库的包装器,也可以使用 Directus 从头开始构建新数据库。从某种意义上说,Directus 是您的数据库的抽象(类似于 ORM,但带有 UI),而无头 CMS 只是其用例之一。这种数据库自检特性在使用 Directus 迁移时为您提供了极大的灵活性,无论是迁入还是迁出。

• 第二名:Strapi

目前,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 中,如果您具有 editor 角色,您可以阅读具有草稿状态的文章(字段条件):if user.role == editor => read draft article

在 Payload 中,每个草稿文章(字段条件)只能由具有 editor 角色:if article.status == draft => allow editor role to read的用户读取。这与 Directus 示例中的权限相同,只是从不同的角度来看。

• 第二名:Strapi

与其他两种解决方案不同的是,Strapi 仅具有 API 级别的访问控制,因此粒度较小。这是一回事,但 Strapi 还将管理面板角色的添加和修改锁定在付费墙后面。由于 CMS 的这样一个基本功能受到这样的限制,我认为这是一个巨大的缺点。

认证

• Winer:有效载荷

Payload 支持双因素身份验证,以及适用于管理面板和前端应用程序的多种策略,如 OAuth 2 和 LDAP。这是可能的,因为 Payload 在底层使用了passport.js,这是一个非常流行的身份验证库,支持超过 500 种策略。请记住,这仅在 Payload v1 版本中引入,并且没有太多关于该功能的文档,因此如果您要构建大型项目,这是一个缺点。

• 画:笔直和绑带

在管理面板认证方面,Directus 与 Payload 比较看齐,但显然没有明确的方法来实现公共用户注册。同时,Strapi 不支持开箱即用的双因素身份验证或任何其他管理面板身份验证策略。 Strapi 的单点登录是一项付费功能,仅在 Gold 计划中可用。然而,Strapi 提供了许多不同身份提供者的前端身份验证。例如,如果用户想在您的电子商务商店中注册一个帐户,则身份验证流程如下。

1. 用户在单页应用程序上使用 Google(或其他身份提供者)登录。

2、谷歌验证身份,返回访问令牌给单页应用。

3. 单页应用程序以 Google 访问令牌作为负载向 Strapi API 发出请求。

4. Strapi 根据提供的信息创建最终用户帐户(假设您事先在 Strapi 中配置了身份提供者)。

5. 您刚刚使用 Google 登录完成了新的最终用户帐户的注册。

也就是说,Directus 和 Strapi 的实战测试时间比 Payload 要长得多。如果仅凭这一事实,您将 Directus 和 Strapi 置于 Payload 之前是合理的。毕竟,安全性一直是软件开发的一个关键方面,但这次我会相信 Payload。

开发者经验

与可定制性和安全性不同,很难客观地评价开发人员的体验。毕竟,经验大多是主观的。考虑到这一点,在这方面没有明显的赢家,下面的比较纯粹是我在测试三个 CMS 时的主观观察。

管理界面

在这三者中,Directus 是开箱即用功能最丰富的。如果你是一个没有代码的人,那么 Directus 肯定是一个很棒的基于 Vue 的选项。它甚至在管理面板中有一个专门的用户指南页面。也就是说,如果您进入 React 生态系统,Strapi 仍然是一个不错的选择。

在两者之间,我更喜欢 Directus 管理 UI。似乎 Strapi 试图在美学上取悦非技术用户,但代价是有太多的空白空间和缺乏功能,我对此并不印象深刻。

另一方面,有效载荷在这里有点异常。这个 CMS 的整体性质是代码优先,所以从某种意义上说,它对初学者不太友好。 payload 管理面板主要用于输入内容(例如,博客文章内容),同时在代码库中定义了其他设置,例如权限、webhook、字段定义等。我想你要么喜欢这种方法,要么不喜欢,而且没有中间的。

文档

这个没什么好讨论的。 Strapi 目前处于第 4 版,而 Directus 处于第 9 版。虽然有些人认为与以前的版本相比,它们的文档都更差,但它们仍然是成熟的项目,因此它们拥有大量的社区资源。同时,Payload 几天前才首次发布,因此与其他两个解决方案相比,显然缺乏资源和文档。

可维护性(升级、迁移、备份、部署)

这将在_Customizability/Database_ 部分简要讨论。根据我的研究,普遍的共识是 Strapi 的可维护性支持非常差。为什么会这样?我不确定。如果您能在下面的评论部分帮助我回答这个问题,那就太好了。相比之下,维护 Directus 似乎轻而易举,因为它只是 SQL 数据库之上的一个包装器。您可以执行数据库级操作或使用 Directus SDK 的功能来帮助维护过程。

尽管如此,Strapi 和 Directus 都是无代码解决方案,通过 UI 配置所有内容可能会在未来产生一致性问题。在 Payload 的情况下,它具有代码配置,因此可以在 CI/CD 管道中对所有内容进行精细控制。在代码库中有效地定义了大多数设置和模式,它还减少了处理数据库中低级操作的麻烦。

托管

默认情况下,Strapi 和 Directus 都需要单独的 Node.js 实例,因此您不能将它们托管在与应用程序相同的服务器上。 Strapi 和 Directus 本身就是完全构建的应用程序。但是,我想应该可以通过使用反向代理的更高级的服务器配置来实现。在两者之间,Strapi 应该更容易部署,无论是简单的 VM、docker 实例还是其他。这是因为许多托管服务提供商因其受欢迎程度而为 Strapi 提供一键式设置选项。

Payload 不同,它更像是现有应用程序的插件。简而言之,您的 Node.js 现在包含前端和作为后端的 Payload。也就是说,如果您想要完全分离关注点,我想仍然可以单独托管它们。

结论

Strapi、Directus 和 Payload,哪个适合构建我的 blogfolio 的目的?在从可定制性、安全性和开发者体验方面考虑这三种解决方案之后,我认为 Directus 在逻辑上是赢家。但是,这次我决定给 Payload 一个机会。一般来说,Payload 在功能方面与 Directus 相当,但它的代码优先方法让我想试一试。作为市场上的新人,最近才发布稳定版本,Payload 可能是一个冒险的选择,但这是我愿意接受的。

本文是记录我对当前无头 CMS 市场的研究的一种方式。作为一个新手,还有很多东西要学,所以我特意跳过了性能、可扩展性、边缘案例等技术比较。如果您正在为大型项目寻找解决方案,希望本文能为您提供一个良好的起点。

---

对 Web 开发、GitHub Actions 等感兴趣?我的其他文章可能对你有帮助!

*高级 GitHub 操作 - 条件工作流 ❓

*如何为您的 Blogfolio 选择最佳的 Headless CMS?

*使用免费和开源软件提高安全性和隐私性,这是一个谬论?

在The Dev Report中查找更多开发者新闻,在我的博客](https://hungvu.tech)中查找技术文章[。

另外,让我们联系吧!

• 推特:@hunghvu_dev

• 领英@hunghvu

• 哈希节点:@hunghvu

• 开发:@hunghvu

• GitHub:@hunghvu

• 黑客中午:@hungvu

• 中:@hunghvu_dev