如题,最近也是闲来无事,就开源了自己博客的评论系统,细细想来也是一段冗长的历史。
想法之初
刚开始写博客啥也不懂,看别人都用 Disqus 那咱也上,其实这个平台没有什么特别大的毛病,唯一的痛点就是广告太多加载太慢国内用户访问不了而已。而后的一两年里基本上试遍了各种评论系统,竟然没有一个我喜欢的🫠。
-
Gitalk,基于 GitHub Issues,很喜欢它的概念,但是不喜欢 UI,而且最近似乎也不维护了。
-
Utterances,同样基于 GitHub Issues,喜欢它的 UI,因为高度无法自适应(iframe 的锅)弃用了,Commits 也止步于两年前。
-
Cusdis,说实话,当时用的时候问题还是很多的,不支持自动暗黑模式,iframe 的问题同样存在,现在可能已经修复了。另外,当用户新增一个评论时,我需要 review 该评论,该评论才会展示在评论区,我觉得这对用户(尤其老粉)来讲不是一个好的体验。
这里提醒一下 Cusdis 作者,官网目前的 Landing page,CSS 是跟随 JS hydration 进来的,这样会导致 “FOUC(样式闪现)” 问题,控制台禁用 JS 可以验证该问题。
这么一通折腾下来,我觉得是个人都会累了,算了,自己做一个吧,顶着前端工程师的头衔,不自己做一个简直暴殄天物!
选型
数据库
数据库不是我的强项,所以我说自己做一个评论系统不是真的从地基开始做,既然已经有多位前辈开路,那就直接选择 GitHub Issues:
- 开放 API
- 防 XSS 攻击
- 易于管理
- 简单的通知机制
- 每个人都很友好
- 如果他不友好你可以直接屏蔽🤡
用户验证
用户验证可以说是最重要的环节,我不想要一个可匿名 / 免登录的评论系统,万一遇到机器人或者垃圾评论会非常讨厌,完全就是浪费时间。在这个项目里我选择使用 GitHub Apps(不是 OAuth Apps),这样基本可以保证用户的真实性,而且 GitHub 的讨论环境相对来说是比较友好的。
至于为什么是 GitHub Apps 而不是 GitHub OAuth Apps,感兴趣的话可以看看我写的这篇博客。
客户端
我想要的客户端:
- 极简,是 minimalistic,也是 extremely simple
- 尺寸小,加载快
- 符合我的审美
- fuck iframe
经过一番斟酌之后选用 Solid.js + TailwindCSS,Solid.js 的打包尺寸只有 7Kb 左右,加上辅助函数和 polyfills 之后,结果还算是比较惊喜的:
vite v5.3.1 building for production...
✓ 21 modules transformed.
dist/style.css 27.97 kB │ gzip: 4.81 kB
dist/cwgi.iife.js 54.07 kB │ gzip: 18.14 kB │ map: 231.52 kB
✓ built in 626ms
JS 代码 18.14 kb,CSS 代码 4.81 kb,加起来 22.95 kb。
服务端
服务端则完全部署在 Cloudflare Workers 上,免费版基本够用,付费版用到死也用不完🤡。
Introducing CWGI
![](https://blog-r2.jw1.dev/sFDvrY4uU_bmBpX6.webp)
客户端其实并不是一开发好就开源出来给大家用了,早在 2022 年 10 月份,我就写了一篇博客关于我如何基于 GitHub Issues 做一个评论系统了,如今你们看到的,就是我用了将近两年的评论系统,也算是有了时间的沉淀。
既然要开源了,总得有个名字吧,思考了一天一夜,决定叫 CWGI,Comment With GitHub Issues。(起名字是最难的部分🫠)
特点:
- 广告去他妈
- 小而美(真的)
功能:
- 使用 GitHub 登陆
- 添加、编辑、删除评论
- 点赞、点踩、打心(Reactions)
基本上只是维持了一个评论系统应该有的样子,我甚至提供了一个选项用来关闭 Reactions,你可以有一个更加干净的 UI。
关于功能点数量问题我想说说我的看法,功能多,可能是众多开源评论系统停止维护的 Break Point,因为维护需要的精力和开发比起来是
Infinity / 1
。所以,CWGI 在之后除了一些正常的 bug 修复和稳定性提升,大概率不会新增任何功能,我希望能把精力用在正确的地方,细水长流才是正解。
已知问题
已知的,也是唯一的问题:我不乐意做公益,也不乐意靠这个赚钱,所以你需要配置自己的服务端。
由于我们需要使用 GitHub Issues,不可避免的,我们需要让游客以 GitHub 登陆来验证身份,这里我们就需要创建一个 GitHub App,而在 App 的创建过程中,我们会需要一个 Callback URL,GitHub 会在用户授权完成之后跳转到这个 Callback URL(API),并且附上一个 code 参数给你用来交换 Access Token,也就是说,你需要一个自己的后端服务,这一步已经足够劝退大部分非技术博主。于是我在文档里提到,你可以使用我部署的 Callback URL,然而这样还不够。
在我提供的后端代码中,还有一个比较重要的代理 (/proxy
) 接口,这个接口做的事情,除了代理转发客户端请求之外,还有一个提升客户端请求速率的功能,你可以在请求头上追加一个属于你自己的 Access Token,这样,即使用户没有登陆,速率限制也是 5000 RPH (Requests per Hour)。
GitHub API 规定,在未认证的情况下,所有接口的请求速率为 60 RPH,很明显,这是不够用的。我去看了一下 Gitalk 的实现,它在客户端放上了自己的 Access Token,这对我来说是不能接受的,即使这个 Token 可能只有 Public Repo 访问权限,他还是有可能会被用来做坏事(DDOS / 冒充身份),我觉得这也是为什么它的前辈 Gitment 在用户未登陆的情况下不会加载评论的原因。
所以,CWGI 的用户有两个选择:
- 跟着教程完成服务端的配置
- 忍受客户端在非登陆状态下 60 RPH 的限制
好消息是,我非常乐意帮忙,如果在配置过程遇到任何问题,你可以在博客下方的评论区中(已经用上 CWGI 了)或者以下任意一个 repo 的 issues 里提问:
出现频率较高的问题我会在文档里更新,这样也方便后来者阅读。