博客架构的更改和原因

•

起因与背景

在二月份时，我着手构建并完成了网站界面的大部分编码工作，初衷是通过整合ContentLayout组件和Obsidian的Git仓库，实现在Obsidian单一平台上同时完成笔记记录和博客发布。这样的设计意在提高工作效率，减少在不同平台间切换的繁琐。然而，随着实际运行时间的增长，一些潜在的问题逐渐浮现。

原架构的问题分析

  1. 耦合度过高：将博客文章与个人笔记存放于同一Git仓库内的特定文件夹里，这种做法虽然在理论上简化了数据管理，但实际上却导致了高度的耦合性。这不仅使得内容分类和管理变得困难，还限制了对博客文章独立进行高级操作的能力。

  2. 标签处理复杂性：Next.js框架下直接处理Obsidian的标签格式并不直观，使得文章分类和标签系统的实现变得复杂且低效。这直接影响了内容的组织和读者的浏览体验。

  3. 自动部署难题：尝试通过GitHub webhook实现自动化的Git仓库同步与网站重建，但遇到了实施障碍。缺乏一个稳定且高效的机制来确保一旦仓库有更新，网站能够自动反映出这些变化，这对于频繁的内容更新来说是一个明显的瓶颈。

现有架构的改进措施

身份认证与后台管理

  • 引入了Dashboard和文章编辑界面，利用authjs集成GitHub身份验证服务，为博主提供了安全且便捷的文章管理入口。

数据存储方式的变革

  • 从Git仓库存储转变为使用SQLite数据库存储文章，这是一个重大转变。数据库不仅提供了更灵活的数据管理能力，还支持文章的版本控制，允许用户轻松回溯和管理不同版本的文章。

Markdown处理的优化

  • 放弃了原有的ContentLayout，转而采用unified等工具直接将Markdown转换为HTML，这样做不仅简化了处理流程，还充分利用了rehype和remark生态系统中的丰富插件，提高了Markdown到HTML转换的灵活性和效率。

用户交互体验的提升

  • 通过重构，现在的网站成为了动态平台，允许在线编写和即时发布文章，大大简化了从撰写到发布的流程，从而激发了创作的积极性。

自动化部署流程

  • 重构后的部署流程变得异常简单，仅需通过Make命令即可完成，而且通过设置GitHub App，可以在仓库变动时自动触发重建和部署，确保网站内容的即时更新。

后续计划与展望

  • 标签分类的深入实现：尽管目前数据库已经为标签存储做好了准备，但实际的标签展示和筛选功能还未实现，计划在文章积累到一定规模时，引入这一功能以提升内容的可发现性。

  • 评论功能的探索：考虑通过集成开源解决方案或自建评论系统，为每篇文章添加评论互动模块，增强与读者的交流。

  • RSS订阅集成：为了满足订阅者的需求，计划添加RSS订阅功能，便于用户跟踪最新内容。

  • 一键备份：为确保数据安全，计划开发一键备份功能，让用户能够轻松备份网站内容。

经验总结

此次重构之旅是一次宝贵的学习经历，它提醒我们在设计系统时要避免不必要的复杂性，保持解决方案的简洁性和实用性。通过不断迭代和优化，我们得以构建一个更为高效、易用的博客平台。