嘲笑满足。
满足（1）与我有点相关建立注意事项与购买决定，我花了一些时间特别感受到了满足在周末，并在这里写了一些笔记。
为什么无头CMSES？
有很多的无头CMSES.在那里，我个人使用的那个是空调。你可以争辩暂停不仅仅是一个无头的CMS，并确定，这是一个很好的争论。作为一个类别，我认为无头CMSES特别好的事情：
- 他们中有很多，所以你不可能发现你的供应商关闭没有“足够好”的替代迁移到
- 内容管理工作流程是动态生存的东西，这些内容经常变化，但一般来说它是过程中的步骤，而不是过程的代表，即核心竞争力。将其卸载到无需工程投资的灵活工具是运营工作流程的团队的大型推动因素，并且允许工程师在最高杠杆作用上花更多的能量。
- 因为他们是无头的，你拥有最后一英里的交付。这允许您保留对质量，延迟和可靠性的控制。它还降低了切换成本，因为您不会要求您的用户对新URL，工具或WhatNot执行迁移。它进一步降低了切换成本，因为它们需要从工作流中的最后一英里解耦。
- 同样的解耦也意味着您可以对朝向或远离CMS进行增量迁移，允许您在开始迁移时尽早移动简单的功能，并且还将您最复杂的工作流程在自定义工具上，如果/当您到达以建立它们时。
- 您存储在CMS中的内容的类型很少敏感。它通常是营销内容或与内容创建管道有关（例如，杂志的文章）。这限制了您从安全或隐私漏洞的风险敞口，因为您无论如何您都没有用户数据。
onboarding.
在进一步前进之前，强制提到我已经在此删除了引用的API键！
我开始满足创建一个新帐户并通过他们的注册和船上工作流程。
我对他们的船上综合融为一体，我很愉快地惊喜，很有希望四个简单的步骤：
git clone https://github.com/contentful/starter-gatsby-blog.git cd starter-gatsby-blog npm install npm运行设置 - \ --spaceid等\ --deliveryToken等\ --ManagementToken等但是，我必须承认我沿着遵循教程的一些问题遇到了几个问题。大多数这些都是针对我当地的环境，这肯定是我的错，但我的经验是，船上的重点是排除沿途可能产生的问题的快乐集成路径。
首先，他们的存储库中的弃用警告有点偏移。
因为您正在使用Gatsby生成静态站点，因此我意识到这里的威胁向量是相当简单的，但它突出了我保持这些类型的持续成本。
其次，我的家用电脑有一个旧版本的nodejs运行，它失败了，错误地失败了：
/users/will/git/starter-gatsby-blog/node_modules/@hapi/joi/lib/types/object/index.js:255！pattern.schema._validate（key，state，{...选项，agometearly：真实}）。错误）{syntaxError：意外令牌...没有任何关于错误引用的错误，但我只是根据以前的调试体验，这是一个错误的调试体验，并且它无法失败的事实，即它已经失败了Lex现代JavaScript语法，所以我已经制作了最新版本
Brew升级NodeJS.这引出了一些侧面追求节点的一点，因为我的房屋架安装在我的最后一个操作系统升级中明显破产，但在一些倾向时，事情就会解决。
升级后，我终于跑了npm运行dev.并对我有一个错误空间没有设置。
TypeError：无法读取未定义的属性“SpacidId”我认为这是由于版本UGPRADE之前的运行设置，所以重新划了npm运行设置来自早期的命令，然后我意识到这是一场灾难一直下降和删除node_modules /并开始了。然后它再次失败了，错误，我删除了package-lock.json.那yarn.lock.lock.和node_modules /并从头开始重新安装做过诀窍，虽然我确实达到了速率限制错误：
12:07:08 - 发生速率限制错误。在重试之前等待1532毫秒......导入成功。我不确定该RATELIMIT是否做了任何事情。似乎是成功的所以我假设不是。他们的安装非常重视SDK，迄今为止，却不提及或引用他们的直接HTTP API。
我是一个强烈的信徒，即SDK是现代的第三方API接口，它将替换HTTP / JSON和GRPC接口，但我认为它仍然有点杂乱，不包括底层接口的链接。从API SPEG比SDK更容易了解API的数据模型和集成流程往往更容易，并且它是不支持的语言的回退（在这种情况下，GO是我注意到我兴趣的语言）。
无论如何，API文件夹在一边，接下来逐步解释了Gatsby示例如何集成WitiH的SDK和API。
这一切都很直，基本上使用您的空间和访问令牌导出所有满足数据。
接下来它将我们带到了示例应用程序的部署页面，要求我们使用NetLify或Heroku。
netlify.作为髋关节和即将到来的部署目标谐振，heroku.是一个很棒的平台，但它感觉有点奇怪，没有一个AWS，Alicloud，Azure或Google Cloud是否得到了指示。也许假设是在那些平台上运行的人才能够解决这个问题，但我认为NetLify或Heroku上的人们也是如此，大多数人都在大型云提供商上。
那个说，为AWS和GCP辩护应该相对简单建立盖茨比网站通过
./node_modules/.bin/gatsby build.然后移动上市/到Firebase Hosting.或者亚马逊S3。
无论哪种方式，此时我都完成了初始教程。
数据模型
满足允许您制作不同的数据模型，这些数据模型基本上是一种用于某种类型的内容的数据库模式或电子表格标题。
您可以创建许多不同类型的字段，包括Matigaliged JSON对象。
完全，这感觉就像一个非常合理的字段和CMS的数据建模功能。当然有其他类型的类型想象想要的，但他们支持的人都是足够的一般，我认为你可以模仿你需要的东西很容易。
工作流程
我想做的最后一件事是花一些时间熟悉工作流程来创建和编辑内容。
作为为Lethain.com创建了三个或四个版本的我自己的CMS的人staffeng.com.，我很欣赏很多小触摸。例如，在将来的发布日期安排是令人愉快的，未来发布和Webhooks的组合是一个聪明的界面，可以在仍然获得正确的功能时解耦内容创建者和工程师。
编辑本身似乎合理，特别是如果你设置了内容预览一体化。
但是，我确实发现可用的工作流程比我从企业级CMS所期望的更简单。一个典型的工作流程，我想象是出现的东西，然后对等待的审核，然后有编辑器审查，然后部署它。您可以执行此类的部分，例如只允许编辑器“发布”内容的权限，但它相当受到限制，更重要的是不促进工作流程中每个步骤的轻松切换。
I imagine you’d end up doing something along the lines of create a workflow content type, adding a reference to the workflow stages in your content, and integrate with webhooks to notify the appropriate folks based on the stage it entered, but that feels a bit awkward to ask each user to model and integrate for what I imagine is a fairly common feature request.
与空洞相比
作为空洞的长期用户，可以使用更专注的无头CMS解决方案很有意思。空调有一个博客文章如何使其成为Gatsby的无头CMS但是，在许多方面，我认为空调斗争来解释自己。维基百科努力描述它，声称它是一个电子表格数据库混合动力，具有数据库的功能，但应用于电子表格。
完全是，我真的很喜欢用满足的嘲笑，一定能够看到它是如何成为一个强大的工具包来构建。