这周接着上周的话题继续来讲，上周给大家简要讲解了Jamstack理念，这种就讲Jamstack中的一个重要的技术: headless cms
在讲headless cms之前，不能绕过cms这个概念，所以我们先来讲下cms。
CMS
CMS英文全称是Content management system, 用中文来表意：内容管理系统
CMS其实包含两个部分，一个部分就是：内容管理，另一部分则为其展现：UI，通常以网页为主
CMS最有名的就是：WordPress。
WordPress是一个开源的CMS，你可以用它来搭建你的网站，它符合CMS的理念:
•它可以存储你的网站的内容，也就是各种文章，图片或其它媒体资源， 也就是支持内容的管理•它有一个Web UI，用来展现你的这些内容，甚至你可以基于它的插件自定义UI的主题等
这就是CMS的经典代表，互联网上6成以上的CMS都是WordPress
局限性
从WordPress这个上面来分析，我们可以很明显感知WordPress的局限性在哪：
1.它的内容基本是固定的，难以扩展
CMS的内容大多是围绕网页来的，所以其内容离不开文章，媒体 ，图片等这些东西。
2. 它的UI载体难以扩展
由于内容是固定的，那显然其UI展现也不可能玩出太多花样，基本也是以文章为中心的网页内容
当然，这个也是完全可以理解的，如果内容不固定，那UI的展现就压根做不到了，对吧，它们实质是相互制约与影响的。
于是，在这种情况下，就出现了另一个概念，headless cms
headless cms
The term “headless” comes from the concept of chopping the “head” (front end) off the “body” (the back end).
我曾经在中文网站上见有翻译成无头cms，这个就有点无厘头了。我们中文翻译讲究信，达，雅，这种翻译可什么都没达到。
并不是所有英文都能准确的用中文来表述，所以我还是建议直接使用headless cms表述为宜
headless cms实质是在借鉴CMS的基础之上，去掉了其UI展现这一部分的功能，从而达到扩充其内容管理的功能。
什么意思？我们对比着来说：
其一：与CMS不同，headless不关心UI展现层的事情，这个事情由最终用户另外去解决。它专注于对内容的支持与管理，提升内容的灵活度。
其二：与CMS另一个不同的是，由于内容的灵活性非常强大，显然它不能提供UI载体。所以它只提供API机制，具体前端展现是什么，怎么样，这个由你自己另外考虑实现
由于上述差异，headless cms有着它自有的优势，也会有一些局限。
优势
•你可以为你的内容定义数据模型，这摆脱了CMS中的文章，图片，媒体等限制，具有极大的灵活性•由于headless cms通常会提供REST API或graphql等方式，意味着前端UI的展现的形态可以多样化，你可以使用网页，或小程序，或App，都是完全灵活的
缺点
•最大的缺点在于你需要自己构建UI展现，这部分工作量是你必须要花费时间去完成的。
案例说明
以【微言码道】的官方来说明
https://taoofcode.cc
如我在上篇文章所言，微言码道的传播载体是多样化的，并非是单纯的文章，我的计划中会包含视频，音频，甚至还有开源的一些项目。那如果我们用CMS来构建这个网站 ，就会发现CMS的局限性非常大，除了文章以外，视频，音频或项目等，都得用文章的方式来做，但这其实并不是非常合适的做法。
以视频为例，视频本身有很多属性，比如名称，所属类别，视频描述，播放地址，封面截图，播放时长等属性，如果使用CMS来展现视频，你只能选择以文章的形式来展现，这其实是有很大的局限性的。但如果使用headless cms,则完全是另一种风格。
我们来看一下如何使用headless cms来解决这个需求：
1. 定义模型
第一步，可以自己定义一个关于视频的数据模型：
如上图所示，headless cms通常会支持自定义数据模型，你可以建立一个模型，并为这个模型添加适当的属性。
上面就是我为视频这个数据模型定义的相关属性
2. 定义数据
添加完模型之后，你就可以添加数据：
如上图所示，我为『视频』添加模型后，就可以为它添加数据。
3. API
headless cms一定是自带API的，否则它就没有意义。而且通常API的范围也很广，包含增删改查多个维度，一些完善的headless cms甚至会带有用户，权限等控制
如上图所示，headless cms默认提供API支持。
一些headless cms还支持GraphQL为类型的查询方式。对于前端来说，这是极其友善的行为
4. UI及载体
在API的支持下，UI则只是一个展现的载体，想要什么样的UI，这就是你自己要做的事情了。
你的UI载体可以多样化，比如网页，小程序，App等都可以。
如上图，微言码道中视频的UI就是我在Gasbty技术之上自行设计与实现的。它的内容则是来源于headless cms。
事实上，我可以随时换掉这个UI，只要我能想像或设计出的任何UI，我都可以实现。
所以，未来【微言码道】的UI也会多样化，我正在考虑App或小程序等其它形态
趋势
通过上面我的介绍，你应该清楚headless cms的能力及可使用的场景了吧。
这就是为什么Jamstack会把headless cms做为它的重要组成部分，这可比hexo,gitbook等使用本地文件系统的能力强大太多了。
而且headless cms的场景还可以扩充，除了我说的权限，用户以外，甚至可以考虑插件化或SDK化，通过类似的机制让用户能二次编码或二次开发，将业务场景复杂化，比如在新增一条记录的过程中，执行一个webhook或记录日志等，或对传入的数据做处理，或自定义逻辑。
headless cms这个东西在国外已经有一定的影响力及知名度了，也有很多知名的商业产品或开源产品，生态已经建立起来了。大家可以自行查阅相关信息以了解更多。
但在国内从我查阅的相关信息来看，似乎仍处于非常早期的阶段，还没有怎么流行起来。
我认为它的可能性及未来还是非常大的。
所以，如果你有类似的需求，当你发现CMS并不能满足你的需求之后，你就可以考虑headless cms了，以及Jamstack.
OK，这一次对headless cms简单介绍到这，我在这就做个抛砖引玉而已，如果你对headless cms感兴趣，可以自行查阅相关资料。
下一次，我继续就Jamstack聊下一个话题，就是构建工具了。
从Jamstack及我在前端的一些编码的感受来看，我觉得前端编码模式相对于后端及移动端，这些年它有了一个质的改变，这就促使我来思考一个问题：
为什么前端的编码发生了质变？
我们下次再聊。
