关于本站的技术相关

1. 当前版本

1.1 主要技术栈

前端：
- 视图：React
- 路由：React Router
- 请求：Apollo React
- 界面：Material UI
后端：
- 渲染中间件：Express
- 请求：Apollo
- 后端：Django
- 接口: Graphene
- 数据库：PostgresQL
后台：
- 管理：Django Admin
- 编辑器：Monaco
- 生成文章：Markdown-it, Mermaid, HighlightJS
部署：
- 系统：Docker
- 网关：Nginx

当前这个版本的博客主要的技术栈如上所示，前端界面继续用的Material Design 语言。
还挺感慨的，我刚开始用这个UI 框架的时候它才是0.0.x的不太有名气的小框架，现在已经到4.x了不久都要出5 代了。

前端是更新的真快。API 设计还不一样🙃

后端改用了PostgresQL 作为数据库，并完善了SSR 服务，完完全全渲染落地页，实现了落地后不用再请求数据，挺好的。
管理后台添加文章精简掉一些数据库表结构，以最简单但最实用的方式只保留会用到的功能。删掉一堆杂七杂八的东西。并自已写了一个Django Admin 的主题，整合了编辑器等一堆自定义的东西进去以提高写文章的体验，总体感觉还不错哈哈，希望接下来能多写点文章。

部署方面还是用Nginx. 区别在于这版所有文件相关的内容，除了放第三方的以外全打包成Docker 镜像了，分得更细更清楚些。

1.2 架构

主要节点如上图所示。

其中每个不同的单元都用Docker 部署，各自分开管理，内部的连接可以Docker 间沟通，只保留主要的入口用于和外界连通。
全部请求使用GraphQL 的方式，通过Django 的后端统一处理，Express 这个服务器也不会有任何和数据库相连的代码，只负责单一的渲染任务。

1.3 补充

1.3.1 渲染层

渲染中间件使用的是Express 框架。完全复用前端的React 代码，渲染的入口直接引用前端的React App 入口文件。省去不同端需要独立适配的烦恼。
并添加自动读取前端生成的index.html 作为服务端的渲染模板，这样直接包含了前期构建的带有静态资源代码链接的文件，当浏览器接收到页面后即可像普通的网页一样读取其中的CSS 样式、Javascript脚本文件等等完全由浏览器接手后面的事情。
当然，服务端渲染的落地页会在服务端生成必要的样式并注入到页面中，所以在浏览器中的React 开始运行后需要检查是否有这部分代码，有则清空并生成自已的样式。

1.3.2 缓存

服务端
在服务端渲染时，Express 会缓存所有请求过的内容在内存中，这样可以减少频繁渲染时对后端带来的没必要的高频请求。并且可以减少IO, 加速返回的速度。对应的优化场景主要是互联网爬虫像百度谷歌这样的情况。
客户端
同样的道理，在前端也会有类似的机制，所有访问过的页面中的请求都会自动缓存，对于想不缓存的请求可以指定每次都请求而不读取缓存。对应的优化场景是浏览人在不同的页面反复切换的情况。
在页面返回时，除了注入的CSS 样式以外，还会额外注入这个实例在服务端渲染中的状态。浏览器拿到页面后，首先会运行React 实例，并从页面中读取服务端的状态，注入到实例中，这样等渲染到具体显示数据的地方时因为实例中已经有对应的数据了，所以不会再走请求网络这边，进一步省掉不必要的请求。对应的优化点是免去了由于服务端渲染而导致的每个页面都请求两遍的情况。

1.3.3 录入文章

这次基本沿用了前面的方式，但将Markdown 转Html 这一步整合到了Django 后台了。
采用的是Markdown-it 作为基本转换插件，HighlightJS 作为代码高亮插件，Mermaid 提供了用Markdown 画各种图的支持。

第一版

第一版时用的是JS 全栈。前端是React + Redux 全家桶，后端是Express. Axios 负责网络请求。Marked 在前端转Markdown 格式。Sequelize 负责ORM.
数据接口按Restful 标准走。使用Material UI 构建前端界面。

第二版

第二版前端主优化。后端开始分离开业务，并开始使用GraphQL 作为接口标准。
文章的Markdown 转换改用Markdown-it + HighlightJS 组合，并定制了一套高亮主题色。期间也折腾过基于Python 的Pygments + Misaka 但是感觉用起来有点太麻烦了。所以也就放弃了。前端这边改用Apollo 代替Redux 和Axios. 负责数据请求和前端数据维护。更深入的优化了打包流程、打包分包等。
后端这边开始用Django 作为“API Centre” 方案。可以整合多个数据库源多个网站等只用一个端点就可以请求各种东西。也开始使用SSR 渲染落地页，但没有做的很完美，前后端的代码还是有点点不一样。而且渲染的不完全只是加速了显示，对SEO 并没有什么帮助。

就这样吧 ~

关于本站的技术相关

1. 当前版本

1.1 主要技术栈

前端：
- 视图：React
- 路由：React Router
- 请求：Apollo React
- 界面：Material UI
后端：
- 渲染中间件：Express
- 请求：Apollo
- 后端：Django
- 接口: Graphene
- 数据库：PostgresQL
后台：
- 管理：Django Admin
- 编辑器：Monaco
- 生成文章：Markdown-it, Mermaid, HighlightJS
部署：
- 系统：Docker
- 网关：Nginx

前端是更新的真快。API 设计还不一样🙃

部署方面还是用Nginx. 区别在于这版所有文件相关的内容，除了放第三方的以外全打包成Docker 镜像了，分得更细更清楚些。

1.2 架构

主要节点如上图所示。

1.3 补充

1.3.1 渲染层

1.3.2 缓存

服务端
在服务端渲染时，Express 会缓存所有请求过的内容在内存中，这样可以减少频繁渲染时对后端带来的没必要的高频请求。并且可以减少IO, 加速返回的速度。对应的优化场景主要是互联网爬虫像百度谷歌这样的情况。
客户端
同样的道理，在前端也会有类似的机制，所有访问过的页面中的请求都会自动缓存，对于想不缓存的请求可以指定每次都请求而不读取缓存。对应的优化场景是浏览人在不同的页面反复切换的情况。
在页面返回时，除了注入的CSS 样式以外，还会额外注入这个实例在服务端渲染中的状态。浏览器拿到页面后，首先会运行React 实例，并从页面中读取服务端的状态，注入到实例中，这样等渲染到具体显示数据的地方时因为实例中已经有对应的数据了，所以不会再走请求网络这边，进一步省掉不必要的请求。对应的优化点是免去了由于服务端渲染而导致的每个页面都请求两遍的情况。

1.3.3 录入文章

第一版

第二版

就这样吧 ~

兵团基地

支持我

友情链接