关于我的博客
建立这个博客的初衷是用来分享和记录我的想法，同时希望这些内容能帮助到需要的人，另一方面，这里也是我的技术实验室，很多技术相关的 idea 会在这里进行实践应用。
主要用到的技术栈：
- Node.js
- PostgreSQL
- GraphQL
- React
- TypeScript
- JSON Web Token
技术栈转变历程 🤖
stage 1 （2016-2017）
这是最初版本，传统的 MVC 模式，统计了一下大概 2000 行代码实现了前端到后端的 CRUD
- Handlebars.js
- MongoDB
- gulp
这个阶段的代码是非常简单清晰的，对于一个简单的应用来说也可以了，虽然它并不容易做组件化和工程化。
stage 2 (2018)
17年开始，我刚好在当时的公司推动前后端分离，当时花很多精力做了一套 React 服务端渲染框架来支持前后端分离，成功把手头的两个项目从 MVC（Laravel + jQuery + React） 迁移到了 React SSR。
有了这次在生产环境的成功案例，加上工作上写了快两年 React，这个时候再来看 Handlebars.js 这种模板语法就很难接受了（由俭入奢易，由奢入俭难）
并且在这个时候我切身体验到了 MongoDB 的一些体验性问题，比如说，相比 PostgreSQL 和 MySQL 它并没有一个我个人觉得很好用的 GUI，整体周边生态感觉要比关系型数据库落后不少。
基于上述背景，我决定将博客系统的技术架构调整为这样：
- 传统 MVC 改为前后端分离，API 和页面渲染拆分为两个独立的服务
- 支持 React 服务端渲染，在浏览器端过渡为 SPA （兼具 SEO 和用户体验）
- MongoDB 替换为 PostgreSQL
整个改造过程大慨用了一个周末加几个晚上，这次重写博客系统的时候顺便单独写了一套 React SSR 工具链 发布在 NPM 上，方便我其他的 Side Project 复用这套工具链。
改造好之后，给我最大的感受就是从农业时代的刀耕火种进化到了工业时代，同样的功能用不同的技术方案去做，开发效率和体验是有非常大差距的。
stage 3 (2018)
想切换到 GraphQL 的主要导火索是因为发现了 REST API 在字段裁剪和聚合方面的不便之处，抱着爱折腾的态度，入坑了 GraphQL，此时主要新增了以下技术栈：
- graphql-yoga
- React-Apollo
graphql-yoga 使用下来也发现了个别蛋疼的问题（比如默认 host 是 0.0.0.0 用户不能更改，为了安全在生产环境还得自己用 iptables 关掉对应端口的公网访问权限），并且相关的 PR 在 github 上一直没有被通过，后续准备替换掉它。
React-Apollo 使用久了也发现不少问题（它会增加不必要的复杂性，对 React 新版本适配也不够快），最终在 2020 年的时候删掉了它，替换为了自己的方案。
stage 4 (2022)
前端迁移到了 Next.js 13。主要是眼馋 Next.js 那一套丝滑+开箱即用的构建工具链（turborepo、swc、还有后续的 turbopack）。加上自己没有太多精力持续维护自己写的那套同构框架了。
目前本站是基于 Next.js 13 最新的实验性 Server Component 架构来实现的，整体上比之前代码简洁了一些，性能方面和之前的版本大部分情况下相差不大。但是在网络延迟大的情况下 Next.js 13 的 prefetch 性能和 Loading 状态管理比我之前那套框架差太多了。
甚至 Next.js 13 的 Loading 目前都是有 bug 的，所以本站目前没有启用 Next.js 默认的 Loading。
其他方面 Next.js 13 的缓存微操能力几乎等于没有，这方面导致用户体验比之前自己写的框架差了不少。
最后，没有完美的框架，有突出的地方，就有不足的地方，而 Next.js 框架的侧重点最近几年一直在往静态化和 Serverless 方向发展，所以势必会有不少功能是很多用户不需要的。
Features 🚀
- Mobile First （核心功能支持移动设备）
- 实时 CRUD
- 代码自动格式化和高亮（现在会使用 Prettier 保持统一的风格）
- 一系列高性能优化
- 文章权限区分公开和私有
- 全文 RSS（Atom 协议）
- 大量 SEO 优化
- 文章 slug 修改后可以自动重定向到新的 slug
本文原载于：baiyun.me