Hexo + Typora 本地环境的弊端 & 为什么要用图床
最近准备求职,想把博客打理一番,因为我是本地环境写的,用过 typora-root-url
应该比较熟悉,是用来配置图片本地相对路径的解决方案,当初觉得挺方便,现在看来是个灾难。
当遇到要整理和归纳时,那些散落的路径问题才知道有多痛。想象一下,两三片文章归纳到一篇时,找路径翻目录的样子真的很狼狈。
PicGo 图床方案一些不可避免的问题
我一直注重两点,就是稳定性和持久化,之前有用 Gitee ,有时抽风是我不能忍受的,还有第三方微博各种奇怪的方案,哪一天链接死了,叫天天不应,叫地地不灵,还是付费安全靠谱。
当我用 PicGo 时,又发现新的问题。难道大家一直用图床都是在白嫖吗?
就是上传后,根本不在乎垃圾产生?(传错不想要了,就算了是吧)
从产品思维的角度上看,上传垃圾不回收,这个闭环就已经坏了,反噬的还是白嫖用户自己,服务商不可能给你白嫖,还要帮你维护这些垃圾信息。
马上我就去了 PicGo issues 和 插件中心找了找,看看有什么管理图床的解决方案。
郁闷了,这产品的初心…应该还是以白嫖为主,这个需求并没有人处理。
虽然 PicGo 的作者提供了插件扩展能力,调用接口返回来的参数是可以实现远端删除的。
我思考了一下,PicGo 插件库还是很丰富的,但为什么没有人愿意做呢?
所以我就发现了新的问题,无服务状态的不可靠性。软件数据卸载清除,再次安装时,之前上传的记录就没有了,远端删除就没了意义。
事实上,我们并不会无故清理数据,但我们的环境很复杂,系统坏死重装,工作环境经常换设备,都是很常见的。
后来我还体验了一下 PicGo 的插件能力,我不知道是用 win 问题,还是作者偏向 mac,我用起来反应比较慢。
所以,综合一些体验问题上的因素,我决定自己开发一个图床工具。
关于解决方案的一段有意思的思考过程
开发可是个大工程,准备压榨脑子前,我得先去 GitHub 上面偷瞄伟大的开源贡献者们。不过在这个图床小众需求里面,PicGo 可能是最好的方案,所以没有抱太大的期待。
观察一圈下来,能实现图床管理的方案,多数是买个服务器部署一个图床服务。我晕,小兄弟,写个博客还要给自己整个运维工作大可不必。(我有自己的产品,服务器运维是真的累)
我发现这些都是以程序员思维去开发产品,要可扩展性,高可用,万一我这个产品火了,嗯,买多几台服务器部署产品,融资走向人生巅峰。
所以我就反向思考一下,不要花那么多时间去想什么高可用有的没的,这些精力应该更注重于我要解决的当前开发目的。(毕竟还要准备求职……)
那如何才能实现无服务端的远端管理呢?
我之前关注过 SQLite,刚好可以解决这个需求。
SQLite 是一个无服务器、零配置的的轻量数据库,将其图片一起推送,就能实现多端同步的效果,不考虑高可用性,对于个人使用绰绰有余。
这个流程模型非常简单,主要分两层,第一层校验对齐,第二层上传并把返回的信息保存,以供下次校验。
弊端:虽然它实现了多端同步,但不能并发上传,也就是同一时间,多人上传可能会出错,所以仅推荐个人使用。
由于篇幅所限,就不聊开发细节了,害,还要准备找工作,我怎么就为了一个图床需求……
但从结果来看,是值得的,我相信这个产品能帮更多人~~
ImSheet 简短介绍 & 预览 [项目已开源]
ImSheet 是一款简约直观的图床工具,无服务端轻松管理你的个人图片资产。
名称由 images + sheet 组合而来,意为能像表格一样直观轻松管理你的图片。
✨ 特性
-
🌈 无服务端实现多端同步,降低维护时间成本。
-
📦 轻松同步添加和删除,上传误操作再无需担心。
-
📑 Link 格式灵活管理,多种交互选择的省心设计。
-
🌠 可控的 Webp 服务,高效节省你的存储资源。
-
🎨 视口自由调节,一键悬挂,优雅地端上台面。
🚀 驱动
ImSheet 基于 Electron + Vite + Ts 、Vue3 构建,由 Sqlite 驱动数据同步,依赖于 COS 对象存储
及转码压缩 数据万象
。目前仅支持腾讯云 COS
🍞 预览
🌈 多少有点彩虹屁,它能一定程度上催更你写博客,应该能吧……
结尾
虽然开发比较仓促,但我向来对 UI 和 交互有较高的标准要求,相信能给你带来前所未有的体验。
关于 Mac 版本,因为我之前的 M1 已经出手了,没有环境 build,近期又在找工作机会准备面试,Mac 用户想用的话,可以帮忙自行 build 一下,ImSheet 全部代码已开源~~
没有过多的时间做测试,使用上有问题欢迎大家来提交 issue 和 Star,关注后续版本~
等安稳后,下个版本计划,添加自定义快捷键功能。
那个 ImSheet 只支持腾讯云 COS,阿里云 OSS 是不是可以 PUA 一下(开玩笑哈
感谢观看 ~