Tiny RDM 新年新版本来了，也顺便总结下使用 wails 半年的感受

Tiny RDM这个项目应该是 23 年 6 月左右建的，8 月正式公开仓库，当时做的目的一是为了验证 wails 开发桌面应用的可行性，二是想学尝试和折腾下独立产品推广和获客。一路坚持下来已有半年，耗费大量时间精力，分文未挣，做开源确实不易~这个版本后会稍微放缓加新功能速度，提高软件稳定性，并尝试下海外推广。

这次更新了什么

惯例先说说 Tiny RDM 更新内容，着急想看 wails 使用感受的，可以直接跳过

• Redis 服务器实时命令监控。可以实时查看当前服务器所有连接客户端正在执行的命令，这也是我最常用的功能之一，随着 go-redis v9.3.1 版本发布，已经支持 monitor 命令，这个功能立马被我补上了。

• 数据的导入导出。Redis 自带的 rdb 备份还是有一定的局限，所以这次先用 csv 来实现数据备份和还原了，能够方便的选择需要导出的数据，同时也可以导入导出 key 的过期时间。

• 批量更新 TTL 。这个在做键批量处理的时候顺便做的。

• 更多细节优化。在用户界面上我花了大量精力对一些细节和布局进行调整，我相信这些细节用户不一定真的注意到，但是他们一定能感受得出来。就是在和竞品来对比的时候，那种“确实差点意思”的感觉🐶。

这个项目第一次在 v 站曝光的时候，很多小伙伴就对 wails 开发桌面应用的可行性感兴趣，我就以个人使用半年的经历，大概总结一下类似 wails/tauri 这类基于 webview 的框架一些优缺点。先给结论：基于 Webview 的应用目前还是不太适合用来开发商业应用，但是很适合想快速做一些小工具的。

优点

1. 打包包体极小。由于并不包含浏览器运行时，所以包体随便能到 10M 以下。但并不意味这内存占用小，和自带浏览器的 electron 类应用相比，实际运行起来内存占用半斤八两，毕竟本质都是 web 应用。
2. 如果你是个 gopher ，又刚好会写点前端网页，那 wails 会是你很好的选择，开发时也能直接浏览器运行，即改即刷新。写些小工具速度还是一流的。这也是我选择 wails 的原因之一，只是没想到 Tiny RDM 它越写越多越庞大了😂。
3. 前后端自动绑定，只要 Go 中声明要导出的结构体实例，写好接口方法，就能自动生成 JavaScript 方法声明，直接调用即可，无论是 Go 端的结构体，还是 JavaScript 端的数组/对象，都能比较友好地进行转换。而且还有基于通知的实现，方便两端进行频繁的数据传输。
4. 可自定义资源服务。这也是基于 Web 的 App 一个好处，通过自定义资源路径来决定本地资源读取路径，甚至是读取远程资源文件，可以以此为基础实现资源热更新。后面有机会也会给 Tiny RDM 加入版本热更新，不用每次新版都跳到 Github 上去下载。

缺点

1. 兼容性一般。这个 electron 类应用的优势就体现出来了，毕竟不同平台上的浏览器内核或多或少都会有差异。有时会遇到一个正常的写法在 Windows 和 macOS 上运行得好好的，在 Linux 上就错位了，这让我想起了 IE6/7/8/9 时代的噩梦。比如在一些旧版本的系统上(有用户反馈 win10 也会)，甚至会出现整个页面都是白屏或者不显示，这相关的几个 issue 目前还躺在那等着大牛来处理~相信随着时间的推移，和新老版本操作系统的更替，这些不兼容性的问题会逐渐消失，基于 Webview 开发的应用也会越来越多。
2. 运行效率一般。后端一些复杂的逻辑和数据处理使用 Go 没啥问题，但是中间涉及到前后端通讯都会有所消耗，而且前端处理能力就摆在那，所以瓶颈往往是在前端。在一些比较复杂的界面，比如树形列表，进行一次大量的增删操作，往往需要拆分多次来处理，拆分后每次处理的量实际也不好把控，数量多了容易导应用假死，数量少了一个完整的操作就需要耗费更多时间。
3. 系统级的接口不够。tauri 相对会好一些，但这个还是比 electron 差太多了。比如我想监听主窗口的尺寸和位置变化，并实时保存变化后的值方便下次启动应用时恢复，也只能依靠些奇技淫巧来解决（新开个 goroutinue 来定时获取和判断窗口是否有变化）。像比较常用的多窗口支持和系统上下文菜单等等，wails 目前也是缺失的。
4. 打包工具不完善。虽然通过 wails cli 就能打包，但是整体还是差强人意，Windows 和 macOS 上还算够用，但 Linux 上就不太舒服了。目前 Tiny RDM 打包使用的是 Github Action ，配置文件部分参考了另一个使用 wails 的开源项目october并做了自定义修改。目前 Tiny RDM 支持 deb 安装包，但是由于 Linux 版本众多，依赖的 Webview 也各不相同，所以 deb 有时都不能做到即装即用，还要安装 Webview 运行时等等（这个问题在旧版的 Windows 上也有）。其中呼声最高的 appimage 格式，目前我也暂时无能为力。
5. 不支持导出 Web 端。这个和上一点说的有些重复，单独作为一点是因为它本身就是基于 Web 开发的应用，大部分人应该都默认它会原生支持 Web 模式了，但实际上却不支持打包 Web 版本，这多少还是有点说不过去。目前开发模式下可以直接通过浏览器运行和调试前端，但也仅限于开发模式下了。并且包括一些系统接口也不支持 Web 端的，如打开对话框选择文件，Web 模式下打开的却是在 App 端的系统文件选择对话框。不过真正麻烦的应该是 Go 后端逻辑没法在浏览器运行，相信随着 Golang 的 Webassembly 逐步成熟，后续官方会支持起来的。
6. 插件市场不丰富。wails 目前没有官方的插件市场，也就只能依靠丰富的 Web 插件和不太丰富的 Golang 第三方依赖了。但比较尴尬的是，NPM 上也只能用使用纯前端插件，而 Go 的依赖大多数是为了服务后端的，服务于操作系统的不多，比如 Tiny RDM 中用到的第三方依赖userdir，用于获取本机中用户数据目录的，最后一次更新是 9 年前了。所以前后端语言都有生态市场，但都挺难用于 wails 。

以上仅仅是一个代码佬的牢骚观点，不代表一个框架一定得有个高低优劣之分，这东西没有银弹，用得顺手才是最重要的，不然可能项目还没做出来，作者就已经先鸽了。所以下一个项目我想尝试下 flutter ，没什么原因，纯属是感兴趣～

最后走过路过，也为 Tiny RDM 赚点吆喝。希望它能给使用 wails 和 vue 的开发者带来一点价值，也希望它能在 Redis 客户端这个领域为用户提供多一个选择。

项目源码地址：https://github.com/tiny-craft/tiny-rdm

项目官网地址：https://redis.tinycraft.cc

此外本人正式开通微信公众号，不定期更新独立开发以及产品相关内容，欢迎扫码关注和交流