使用headless cms + ssr渲染框架来开发网站
2019/11/25 11:15 frontend

前言

由于我是一名前端开发者,偶尔会接一些私单,最主要的无非就是帮人做网站了。

CMS

根据以前的经验无非就是前端写完界面,然后找一个cms去套,但由于国内的cms框架(duxcms我之前一直用,dedecms.phpcms,wordpress)已经很难满足了现在的客户需求了。

比如做个网站,一开始以为做个网站就行,谁知道还要做小程序,App等等,但之前的cms都不带api,即使有写带比如wordpress,api接口也是问题多多的。

然后可以看国内开发的cms,即使的新开发新产品,也是比较保守的,还是跟以前的cms差不多,无非就多提供了api 供用户调用,然后后台操作界面交互也不咋地,所以很难找到一款非常合适的cms框架。

​ 而我感觉国外的就比较思想超前敢冒险尝试,既然api方式通用,那我就专门做提供api和后台内容操作的cms,数据和界面教还给前端,自己爱拿什么数据那什么数据,唉什么布局怎么布局,前后分离。然后cms就专心做好内容管理和api接口的设计就可以了。

虽然这个想法早期还有点冒险,比较像这种前后端分离的spa还有有很多问题的

  • 做网站的人很看重的seo问题
  • 首屏加载速度问题

问题虽然有,但方向应该是对的,就看怎么解决这些问题而已。

为什么写网站也要用spa

​ 而且平时在公司或者自己写前端,写法习惯都已经从jq过渡到了前后端分离框架vuereactangular等写法的习惯了。然后接了一个私单,又要突然转回去以前那种jq操作dom的 时代。

这个过程实在难受,而且效率也低。

有没有办法开发个网站也能使用现代化的开发流程和各种工具,然后解决seo,和首屏加载慢等spa问题的。

于是乎后面出现了各种ssr服务端渲染框架,去帮spa应用解决这些问题。

SSR 服务端渲染框架

使用SSR(也称为“通用”或“同构”)模式,将使用Node.js服务器将基于Vue组件的HTML传递给客户端,而不是纯JavaScript。 — nuxt.js

目前主流有两个:

  • vue 架构的 nuxt
  • react 机构的 next

两个都是开箱即用的,大大降低了开发部署的难度。

主要用那个技术栈就用那个框架吧,react好像还有个 gatsby好像挺好用,但我不主要react技术栈 ,所以就没深入了解了,看了文档和别人介绍感觉挺不错的,react技术栈的同学可以去了解下。

前端的开发框架我们选好了,然后我们就要选个后端的cms 去管理数据,提供api接口调用数据了。

我们先来想一下我们期待的cms是怎样的:

  • 内容可定制化程度高,因为网站有各种功能,比如轮播的海报,收集用户表单,新闻站的文章,画册张的相册等。

  • 后台交互良好,至少交付给客户时,客户很快有会用。

  • 良好的api接口设计

  • gatsby友好

  • 提供全平台sdk

headless cms

翻译一下就是只提供纯api的cms,不包含任何客户端代码,也就是老子只负责api你手机,还是网页想咋用咋用。 — 摘抄自北方蜘蛛

Contentful

你搜headless cms,然后到处都能看得到Contentful

来说说它的强大之处:

  • API-First CMS to Power All Digital Products | Contentful

    简单翻译就是第一个只提供api的cms吧,先做有经验优势嘛

  • 免费,不用自己部署,但有一定限制

  • Serverless 架构部署,可能就是用了serverless 才有可能有免费的提供用吧

  • 提供restful 接口 + graaphql 接口

  • 支持多站点,多项目,但需另外收费。

可以说contentful是个先进技术集合的cms,各种现代化技术集合一体。

然后操作界面也比较简单简洁,感觉是挺不错的,操作还是流畅的,还提供多角色共同管理。

image-20191114163315536

但作为接私单来开发网站还是有些问题的:

  • 不开源,所以不可以自己部署。你做完交接,要客户登陆别人的网站去管理,这样不大好吧。

  • 后台管理不支持中文,怕客户看不懂,不好操作。

  • 不收费的有限制,感觉以后也会慢慢变成收费的,收费项又确实比较贵

  • 暂时没看到内容的导出与导入

strapi

我试了挺久的一个,功能也简单,界面也简洁。

优势:

  • 开源免费,可以自己部署

  • 简单又便捷,添加内容模型,添加内容,然后设置用户对这个内容接口的权限就好了

  • 规范的restful接口,且接口信息简洁,没有返回其他很多没有必要的东西

    ///banners
    [
        {
            "id": 1,
            "title": "轮播海报",
            "link": "sadasdasdasd",
            "created_at": "2019-11-14T07:19:50.350Z",
            "updated_at": "2019-11-14T07:19:50.350Z",
            "image": {
                "id": 1,
                "name": "teacher-avatar.gif",
                "hash": "466289966ffd4599afd646ede29bac40",
                "sha256": "kgeU5VQ-bYTbtNlEwoTi_4LPykpIPxrtZLtlL-ehyAY",
                "ext": ".gif",
                "mime": "image/gif",
                "size": "1.48",
                "url": "/uploads/466289966ffd4599afd646ede29bac40.gif",
                "provider": "local",
                "provider_metadata": null,
                "created_at": "2019-11-14T07:19:50.471Z",
                "updated_at": "2019-11-14T07:19:50.471Z"
            }
        }
    ]
  • 后台字段布局可自由拖动布局

  • 有国际化,虽然中文的有些翻译有些蹩脚,有些也没翻译,但总比全英文好啊

  • 也提供Graphql接口

    感觉strapi虽简洁,简单,但功能齐全

个人感觉的缺点:

  • 不支持多站点多项目

    比如我想自己搭一个数据管理中心,给个各个网站使用,每个网站都有新闻内容模块

    这时候我不能建一个新闻内容模块一起用,这样数据就混乱了。只能布置多个strapi或者新建多个新闻内容模块,以区分不同网站的新闻内容模块。

    其实有考虑过根据新闻模块关联用户、根据用户去区分新闻模块对应的数据,这是一个可行的方法。但只只对没有用户系统的站点或项目,不然就又轮到用户信息混乱了。

    但是用户又可以根据用户组去区分,感觉还是可以实现的->

    根据添加不同用户组然后添加用户,去区分不同的网站,从而去同一个内容模型拿对应的内容数据

    但说回来,要不同项目用统一个模型,两个项目的统一模型要高度统一,不然还是有很多问题的。

    期待strapi后面可以有站点或者项目的概念,在站点或项目下,再去新建不同的内容模型,这就完美了。

ghost

我用过算最好的博客系统吧,性能飞跃,后台管理、写作交互,体验都完美,也有很多很漂亮的,后来因为服务器到期了,续费太贵了,于是才把博客迁移到了hexo+github pages 免服务器啊,还可以https,当然速度和原来的没法比啊。而且你githubnodejsheadless cms 第一名就是ghost,第二是``strapi`

个人感觉的优点:

  • 简单简洁,为博客而生,主要就添加文章或页面
  • 完美的写作体验,完美兼容markdownhtml 写作,也可以一篇文章即html又有markdown
  • 主题精美,速度飞快,后台操作也很友好
  • 即提供服务端渲染,也提供api
  • 代码开源,却已盈利
  • 完善的开发手脚架,不仅可以初始项目,更包括集成 Let's Encrypt 自动帮你生成ssl证书,配置nginx ssl配置,等等……

个人感觉的缺点:

  • 主要专注于博客,对于一些网站的其他功能还是显得有些不足。可扩展性不强。
  • 虽提供api,但不是restful 规范的
  • 主题虽精美,但相对于wordpress 还是相对较少的