或者您可能不想为其扩展而付

rmruhul

因此出现了自托管的无头 CMS。我们不是其中之一，因为我们倾向于瞄准更大的客户，这些客户再次对这些 API 有这些需求，而我们的 CDN 每月接收数十亿个请求。所以我们非常适合高流量的东西。但是，是的，您可以安装一些解决方案，Strappy 是自托管的解决方案之一。您可以将其安装在您自己的服务器上，正如您所说，这将为您提供无头 CMS。您将拥有您的内容，您将获得 API。但显然，这样做的缺点是，如果您获得大量流量，那么它将进入您可能无法扩展的服务器确实如此——但这是肯定有可能的。

德鲁：我想你必须管理它，如果它在你这边，你必须保持它更新，保持它运行，保持它备份。我想如果您是宜家，您为小型社区网站所做的决定会有所不同。宜家可能不会在 VPS 上运行 Strappy。从很多方面来说，这对他们 电报号码数据 来说可能不是一个好的解决方案。那么，在选择无头 CMS 解决方案时应该权衡哪些因素呢？需要注意哪些事项可能与我们习惯评估的传统 CMS 有所不同？

阿尔文：我认为这取决于……好吧，作为一名开发人员，您会知道您将编写什么代码，因此您可以查看 API 及其外观，无论您是否喜欢。很简单，它支持 GraphQL 吗？现在每个人都这样做，但类似的事情。然后我认为这取决于那些将在 CMS 团队中花费大量时间的人。如果我喜欢 API，这对我来说很好，但如果要在 CMS 中编写的人讨厌它，那么它可能不是正确的选择。所以我绝对认为你可能想让这些人参与决策，对吗？因为他们将是花时间的人。对于我们来说，我们希望确保作为开发人员能够从 API 中检索我们想要的所有内容，但绝对希望您的博客编辑为您开绿灯，并确保它拥有他们需要的所有内容。

德鲁：是的，你提到 API 变得非常重要，我已经看到了带有 Rest API 和 GraphQL 的无头 CMS，然后各种解决方案都有 SDK，你可以将它们导入到你的项目中，为你提供一种语言原生的交互方式。从开发的角度来看，在评估 SDK 或 API 类型的可用性时，您需要注意什么？



阿尔文是的当然，如果这是你喜欢的东西。归根结底，它的美妙之处在于它仍然是一个 API 调用。因此，希望世界上任何语言都可以支持这一点。是的，所以这也取决于你，对吧？你想要Python原生SDK吗，就像，好吧，我输入三行代码，然后我做客户端，获取条目，得到这个想法，或者获取属于这种内容类型的这些条目，他们更喜欢那个等级。但是，如果您是那种会说“不，我将拥有完全控制权”的人，那么这也可以追溯到您所说的关于拥有自己的数据的内容。依赖 SDK 的问题是，当存在安全问题时会发生什么，而如果是您，并且您只是在您的语言上使用简单的 HTTP 客户端，则风险较小。因此，这还取决于您正在从事的项目类型。

德鲁：您谈到了用户界面方面，它一定是重要因素之一，不是吗？当人们输入内容、在系统中创建内容并对其进行管理时，提供的用户界面以及数据的方式是一个重要因素……有各种各样不同的方法，不是吗？在内容管理中，您如何管理数据，无论它只是一大堆垃圾，还是将内容分解为结构化内容的粒度级别。假设大多数无头解决方案仍然具有某种用于编辑内容的用户界面来帮助您入门，这是否反映了您在市场上看到的情况？

阿尔文：是的，每个人都有一个wizzywig。有些对 Markdown 有不同程度的支持，再说一遍，我正在谈论的应用程序生态系统。所以越来越多的玩家拥有自己的，这也有助于扩展它，这样它可以帮助讨论，如果你正在与博客编辑交谈，就像，“啊，它就在那里，但我真的希望有一个领域可以做 X”，你可以自己扩展它，或者只是寻找另一个解决方案。但是，不同的团队有不同的需求。它可能是一些小事情，例如日程安排。就像，哦，我希望能够让这个活动继续下去，我想确保从现在开始，我可以确保一篇博客文章在星期一发表，另一篇文章在星期二发表，另一篇文章在星期四发表。如果与您可能不需要的其他东西相比，这个界面是一场噩梦。这要看情况，对吧？总是……但是，是的，这很重要。绝对地。