YukiLog - 1 - 新生

从用现成框架到决定自己写一个——这篇记录了 YukiLog 的起点,以及我为它选择的技术栈

📚 引言

我之前的博客是基于 valaxy 搭建的, 那是一个极简且优雅的开箱即用框架

但是我总想要自己全栈写一个系统出来, 这样就能获得最大程度的自定义, 也可以自由的实现自己喜欢的页面

如果你对源码感兴趣, 可以直接跳转 Yueosa/YukiLog


🖥技术选型

老实说技术选型我思考了很久, 因为我本人最熟悉的 Web 框架当然是Python-FastAPI + 原生HTML+CSS+JS

不过考虑到性能, 以及为了脱离自己的舒适区, 我最终选择了以下技术栈:

| 后端

后端技术我选择了 Rust + Axum + SeaORM

  • 我个人一直都喜欢 静态强类型 的编程语言, 追求 编译能通过就不报错, 除了某些因为设计出现的运行时错误外, Rust 刚好满足了我对编程语言, 运行效率的要求
  • Axum 则是一个基于 tokio 生态的 Web 框架, 异步运行时在任何全栈项目中都是重要的
  • 数据库方面, 我这次不打算手搓ORM了, 所以选择了 SeaORM, 他的好处是一行命令就能生成 Rust 基础数据结构

| 前端

前端技术我选择了 Astro + TypeScript

  • 这是我第一次接触 Astro 框架, 他的优点是使用岛屿架构, 构建阶段就可以生成静态 HTML, 在需要的位置插入动态的 Vue 组件
  • 评价 TypeScript 就必须聊到原生的 JS 是一种 动态弱类型语言, 也是我最抗拒的一种语言, TypeScript 在他的基础上实现了 静态类型 支持, 并且是一门 编译时检查 的语言(JS 是运行时检查)

| 数据库

数据库技术我使用了 PostgreSql + Redis

  • psql 作为主数据库存储数据
  • redis 作为缓存和会话管理系统

👋 最后

这是 YukiLog 系列的第一篇博客, 不知道写什么好, 所以就记录一下技术栈吧

关于弃用 valaxy 的真实原因

我最开始想要搭建一个博客的时候, 其实并没有信心去做全栈, 于是就挑选了一个框架

随着我的需求越来越复杂, 也是因为我没有时间去详细研究一个框架的源码(这个框架当时并没有 Web 管理页面)

编译时间太长, 编译内存占用太高, 评论区等功能依赖外部服务 ...

我想...我还是没有能力去用好一个框架, 也没有付出足够的耐心去研究 别人写的东西

YukiLog 的新生

于是我决定自己去写一个 CMS 系统, 如果所有代码都是我完成的, 我就能控制他的版本, 内存开销, 高级服务...

同时也是为了学习更多东西, 为了在学习过程中证明自己, 为了亲手创造些什么 ...

这就是 YukiLog 的起点, 硬要说的话, 他只是我自以为是赋予意义, 又自以为是倾注心血的产物

💬 评论区

留下你的足迹,分享你的想法

0 / 500
支持 Markdown 基础语法 · 提交后需等待审核
💬

这里还没有评论,来做第一个进来的人吧~ ~