我是如何构建这个博客的

created At : 2022/05/25

updated At : 2022/05/25



来历

我的博客应该是从react的学习开始的当时采用的是react一个SSG生成器(https://docusaurus.io/zh-CN/)当时学完react便觉得想使用react大干一番,:)。想法是美好的,当然结果也是非常美好的。Docusaurus生成的博客很美观,而且样式上也无可挑剔。那是我第一个部署到vercel上真正意义的博客。

从这个博客小恐龙生成的框架下放入md文件再dev,一个默认模板包裹的博客就这样平平稳稳地生成了。但是呢,当时貌似觉得这个小恐龙博客框架不是那么好改动,自定义地文档也没有中文,不过现在有了😆。

后来使用Nextjs感受了一下顺便部署了一份,改动起来也不是很麻烦,当时react还是非常熟悉的,而且十分膜拜react地jsx语法,这玩意不是比vue用起来爽很多?jsx的js和html混到一块写起来的写法很方便,除了一直没能明白react的css好的解决方案一切用起来很顺利。
但是博客的部署流程一直都是非常不优雅的,用前端工具搭出来一个框架放入md再Push到github仓库,vercel的机器人发现github仓库更新了就会触发重新部署,vercel的服务器再次部署就会拉取到新的md文件,这样内容就更新了。实际上的操作也不多就是更改,push这样一个操作就能达到持续部署,自动化的效果。但是这个还是很讨厌就是,没有办法随时随地向上传文章或者说闲空地时候,有了灵感地时候,就没有办法诉之所求了。只能借助于石墨文档,语雀这样的在线文档库。但是这...我还要博客作甚么呢。
于是,借助于v2ex的一个帖子开始了我的再构博客之旅。

关键词:headless CMS,SSG

后端

首先我就在部署这块想办法改进,试图加一个后端服务,当我看到v2ex提及的headless cms我就去找到了Strapi,ghost这些知名的CMS,说是headless其实就是一个能让后端失业的产品,写好的数据库和中间件,暴露出接口让你调用,不像wordpress前端都给你做好了。其实也是前后端分离的结果,wordpress一些非无头cms呢大部分还是服务端渲染出数据包裹好html是由服务端的php渲染的都是在后端完成的一系列效果。这样我们就确定了headless的cms可以解决我所想要的后端服务,通过这个cms我可以直接在这个everywhere都可以用的地方写我的文章了,更前进一点的话我可以自己做一个后台利用他的CRUD接口自己就可以在自己自定义的后台编写文章岂不美哉。
理想很美好,做起来很复杂。
strapi_dribble (1).png
尝试了最为出名的Strapi这个logo非常好看,后台也很精致也是很多企业和组织都在用的无头cms常用一些不太复杂的业务和博客,当然后端不会因为这个失业的啦。因为后端岂至crud还有很多复杂的非模板化的东西算法运算之类,但这个简单的博客内容系统用无头cms还是戳戳有余了。
Strapi一经我的使用就出现了非常头疼的问题,并不能很好的安装,这里还是主要是环境的问题,在这边做个小tip吧


Strapi安装

总之由于环境和国内网络 让strapi的安装十分抓狂
同时在windows上也非常难以安装 以下是在linux node环境下

1.gcc编译器缺失 某个node包需要编译 (strapi/ghost)
gcc在strapi下一般需要>4.x

https://blog.csdn.net/BUG_88/article/details/106235196

2.node版本不对
有的包需要node 16或12,14的某个特定版本下才能运行
nvm安装即可

https://www.cnblogs.com/shuiche/p/15721801.html

3.npm sharp的网络问题

https://sharp.pixelplumbing.com/install#chinese-mirror

Chinese Mirror npm设置sharp镜像

4.node守护进程问题
node进程常驻系统 使用pm2
linux/tips:
0.0.0.0 是对外开放,说明80端口外面可以访问;127.0.0.1 是只能本机访问,外面访问不了此端口


安装之后但是Strapi还是有个基于graphql的接口,试了半天不行,一去查graphql结果发现graphql这个四五年前诞生也很火的东西现在基本上是无人问津。听说因为是需要后端操作且提供接口所以非常麻烦且不易,然而我也查不到什么相对有用的资料折腾之后我还是放弃了Strapi。放弃之后想法是转向第二大的ghost cms没想到这家伙更加复杂难弄一堆报错且查不到办法解决,没有办法再让我继续下去了。转而走向Netlify CMS这家伙基于GIT听说还可以,但是使用了一下发现体验并不好,netlify在国内的速度堪忧,比起vercel还差的很远。CMS是基于NETFLIFY的说实话并不是很想用,条条框框稍微有点多了。

directus

最后我还是投向了这个略微有点丑的带着山羊logo的directus,说实话这些无头CMS可能是国外比较火的原因,一但安装报错在国内难以查到相关资料,在国外甚至也是有很多热乎的错误。反正就是安装永远不可能顺利,多少都会带点node-gyp这样的难搞东西去跨语言编译导致不少报错(node-gyp的环境参照仓库的md可以解决)。最后惊喜地发现directus甚至有自家地部署云服务,比起Strapi和ghost更重要的是他免费。用起来很方便,直接不需要我在我买了一年的腾讯云应用服务器上部署了。当然我这服务器钱也白花了,一直想用来把服务器做后端很轻量传的东西小带宽也能用。更好的是我对这个山羊CMS有了很大好感。因为cloud自定义域名找不到地方的问题,特地去discord问官方频道,里面还有个新加坡好像是core team的人热心帮我解答了确实自定义不了。特别感谢,这说明这个CMS还是值得信赖的呀~虽然没花一分钱。真向directs表示感谢现在的博客全自动部署都是基于directus的服务。

前端

找到了山羊cms,后端解决了接下来是前端了。前端是一个擅长领域是吧,但其实也不是。我对博客的静态部署了解也十分孱弱,只会SPA的三脚猫功夫。因为一直在公司用VUE2就顺利成章地使用了NUXT.JS。在2019年左右学前端的那时,真心觉得NUXT是一个非常酷的东西。当时伴随着NUXT的名词有服务端渲染等等,VUE的更上一级框架,而且LOGO我觉得设计得真心好看自然之美。

NUXT-CONTENT

这次也是稍微了解了NUXT,前端有三种渲染方式SPA,SSR,SSG。SPA就是基于JS渲染,真正的一个基于首屏的APP,页面渲染依靠JS。SSR就是服务端渲染好数据传给客户端,需要一个NODE环境把html字符渲染好,在客户端做个js的激活。SSG就是纯静态资源的生成,数据当然都是写死了。想了想之前博客的一大痛点是有点丑,不够简约,字体是一大痛点,不同字重试了默认的字体都不是很好看如果是苹果的话苹方会不错,但很明显我没这钱有苹果电脑。这就有点限制了我选择SSG,因为SSG快,可以SEO,且自定义字体方便。当时我想的是SSG可以提前知道需要哪些字,使用那些字体提取工具会很方便。所以我就依旧使用这个最适合博客的SSG,因为博客改动小,主要是看,美观还是第一的。

使用nuxt的时候主要是怎么做这博客的渲染呢,发现nuxt自带一个非常不错的适配markdown的插件nuxt-content。有非常多强大的功能,甚至还为内容提供api接口,这个我真想不出来怎么实现的。但是nuxtcontent首要就是放在/content目录下读取md。这个怎么办呢,我现在是基于后端获取数据,而nuxt-content是需要读取目录下的md文件。我就直接用了gulp类似编译前在node环境下先去向后端拿数据写入/content文件夹,这样我们就有了nuxt-content的数据源。再次dev发现这样是成功的。

字体压缩

那么一个博客的基本逻辑结构就形成了,那么怎么弄字体那边的压缩呢。这个其实还是比较麻烦的,尝试过font-spider也就是字蛛,字蛛需要参数.html也就是html文件作为参数。那我在nuxt generate用font-spider去压缩不就行了嘛。然而这东西是不起效果的,因为nuxt生成的静态文件路径有点问题,字蛛找不到字体文件在哪,路径是基于服务器的根路径,类似/resource也就是说只有在启动服务器的时候才会被指向正确的路径,在windows下直接使用一般都会把根指向盘符。必应,谷歌,百度发了疯似的寻找这个Nuxt解决导出路径的答案,结果还是找不到。想了半天写个脚本去全替换成相对不就行吗,然而这是个愚蠢的想法,不同的html嵌套层级还不一样直接加个点完全找不到。那我想有个想法,在获取服务器的数据时填充到一个html再去从这个html解析字体不是很好吗。确实这是个偏方。但是我发现更好的font-min库,这个库的参数是基于字符串,给什么字符串它提取什么字体并输出字体包。这样我从服务器下获取的数据直接转化为字符串再给它入参不就行了吗。我最后把这个写成了脚本放在了script里在最后生成时对生成的font文件替换达到了预期的效果。在vercel上这个字体包也缩减到了几百k。已经是个很不错的成果了。

自动部署

这个自动部署就比较简单了,在directus里有webhook直接填入vercel给的触发url,当cms的数据变动时就会触发,待vercel收到后就会对仓库进行重新部署,这时候会获取最新的数据,生成新的md,生成的页面也将会是修改后的。这样就初步实现了everywhere write的目标。想想处处可以写就很激动,这时候比起之前的流程不需要你去git clone一个下来去修改md这种繁杂体验不好的写作方式。

现在,你可以在任何编辑器编辑想要的内容制作成md,复制粘贴到directus即可。这时vercel又会默默地重新部署,虽然需要点时间,website会pending最后才生成静态文件,但这个真的很棒。大大改进了我的博客写作流。以后完全可以再写一部分后台内容,然后直接在后台的网页做一个axios的请求更新文章。甚至不需要进cms。这样的体验真的很棒哈哈。