项目介绍
这个项目是我的博客源码,里面的一点一滴都是是纯手工搭建起来的。不依托于任何 CLI,可扩展性强,所有配置开放。
项目地址: 点击这里 ,如果能解决你升级技术体系的痛点,欢迎和我一起学习
至于这辣眼睛的样式,勿喷~~~
项目搭建使用的技术
- react
- typescript
- less
- react-router-dom
- nest
- hbs
- antd
- WRK
- marked
- jenkins
- pm2 + ts-node
- webpack5
- http2.0
- highlight
- helmet
坑&&变化:
第二次重写博客遇到的坑
- 前端构建忘记使用 publicPath,导致动态路由资源引用错误
- 相比于第一版的 Marked,解决 Marked 与 SSR 冲突的问题,可直接渲染出静态化
- 相比于第一版打包,使用 Webpack5(Prepaack)体积更小
- 不依靠 Nest Cli,将上一版的 Koa 更换为 Nest,秉承经典 MVC、DI、装饰器的写法等
- 使用 Ts-node 部署及运行,毕竟都是静态编译
- 使用 Nginx 搭载 Http3 失败,Nginx 运行失败
最近要解决的(把算法整理完)
- splitChunks 进行打包优化,目前并未提取 common 以及三方资源,导致目前 main 太大
- 算法是我的短板,最近要加大药量
- 源码分析不透彻,可能也是一年前生吃,不写项目的原因
- 该项目并未加入 log4js、jest、一套匹配的 eslint(一套好的 eslint 真的能进步很多)
- typescript 高阶泛型欠缺
- 没有数据库,虽然 mysql、mongodb 都玩过(后期博客完善后考虑)
- 缺少性能监控工具
- ……
2020.5.15 关于 SSR 优化
首先,我们要明白 SSR 解决的是什么
- 真路由加载太慢,需要等待静态的返回及脚本的驱动
- 静态化欠缺,几乎没有 SEO
带来的缺点
- 加大服务器压力
- 对开发者要求提高
- node 运行时,禁止 Dom 及 Bom 的操作
需要明白的简单原理
- 数据同构:利用 redux 等作为 server&&client 代码块数据管理,简单看一下:
. server: 解析执行 client 请求
. redux: server 执行 client 代码,将 state 注入至组件中
. render: 返回渲染好的 Docs,注水
. window: 注水数据存放
. redux: 脱水,将注水的数据(state)提交至代码块中
. mapStateToProps: 将 state 传到 components(page)中
. props: 已拿到 state,对比是否需要请求
- css 同构:将当前真路由页面所需要的 css 渲染出去
- 可以考虑使用 isomorphic-style-loader 提取需要的 css
- 可以使用 Jss 等方式,但是个人觉得 css in js 不爽(而且影响搬砖速度)
- 路由同构:前后端路由统一对应
- 路由安全
- 区分 node 不能执行的对象,例如 History 等
- node 代替 client 请求
如何选择技术
- node 中用了 Nest,包括 Nest Core,Nest Common 等,相当将 Nest cli 中核心的部分拿了出来,个人觉得 Nest 比较靠前,经典的 MVC、比较先进的 TypeScript、思想比较老练的 DI(依赖注入)、装饰器等
- Marked: 与 highLight 结合的比较好,Markdown 比较好看,唯一缺陷就是容易被注入式攻击
- Redux: 经典 Flux 思想,函数式编程
- Pm2:比较稳定且强大的辅助工具
- Less:容易且比较轻快的预编译
- Typescript:将来(目前)使用人数最多的语言
- Jenkins:工程化的鼻祖,社区完善,生态强大
- ……
目前未改善
- Jest: 自动化测试,UI 对比,覆盖率测试等
- log4js: 容错不完善
- WRK: 压力测试
- memeye: 服务性能监控报告
- tsDocs: 清晰注释、泛型等
- esLint: 未配置一套严格且友好的代码格式工具
- 缓存: Http 缓存、本地缓存
- 预渲染: 对于 SSR,加大 DOM 缓存力度
- Http3: Ngnix 有库已经支持
- Nest 打包成 js: 作用不是很大,属静态编译
2022年2月更新内容:
- 升级HTTP3.0
- 完善CSS 同构
- 升级代码规范
逆天改命
袁志佳 京程一灯创始人
@ 京程一灯
痛哭涕零,感激不止