并且可以经常全量订阅和刷新

需要先做一下调查，想必应该差距很小，即使上千篇文章🙃🙃🙃

如果我的小米 2s 扛得住，我就这么改

工作量很大，所以我很想要有人能和我一起开发纯纯写作，但又很矛盾，因为除了自己，很难有人能够达到我对代码的要求...所以只能一直自己一个人开发下去

我差一点又要 angry 了 😶 不过我很冷静

不过我也不怎么了解 SQLite internals

实际上是完全不了解，所以我没有什么话说，但就这个讨论了这麽久的排序问题我还是很醉

搞不懂这麽一点数据还考虑啥性能

就那几个字放内存里都可以，只要不会丢失

FreeType 那个莫名奇妙的 Uppercased_Snake_Case 有点奇怪

暴力测试 😶😶

新的 Rebase 就叫做 RebaseW

使用 Crystal + router.cr 编写，不使用数据库

很酷

当然，我花时间写 RebaseD 不是说「崇拜」drakeet

（下面的话开开玩笑别当真）
以他说话的风格：
这个 API 很烂，不过我不知道为什么，反正就是垃圾，因为我懒得看他写的文档

Drakeet 开始说 「For Everyone」、「Opensource」 可是后来闭源了
这个 API 本身也很简单，根本不足为题，尤其是 drakeet 的那部分，这种接口分分钟设计一打，然而就这 drakeet API 都写了 4 天才基本能用，在我看来这就是个笑话般的项目，很可惜（XD

一是看他有经验，二是拭目以待。
可是呢，逐渐发现他是一个做完后骄傲到爆的人，做成一点东西就自信满满，以王垠为偶像却不肯好好学习计算机科学知识只 fork 了一个 Scheme 写的 interpreters 可能连 S 表达式都不会看，就是烂泥土也糊不出破墙这样子

当初看了一堆非常不成熟，甚至可以说幼稚的空壳代码和定义，连语言稍微内部一点的东西都不明白，还认为自己质量很高，但哪怕是文档的代码风格很水，还拒绝和别的开发者讨论，实际上在我看来非常水和不专业，就像 Gekyll 开源在 Gist 上的编译输出部分一样

GeekApk 开始设计时已经覆盖了它所有设计（比如 Token），没有什么可以说胜过 GeekApk API 的，而且就工程大小来看远远不及 GeekApk 的十分之一，模型数量只有 GeekApk 的三分之一

另外，说实话，文档里“Truly open source”、“Never lost source code project” 就是讽刺 Drakeet 的 rebase-server 的，因为我是真的开源，而 drakeet 把那个破烂这麽简单的应用还用 MongoDB 的玩意当个宝似的，写的时候居然还花了四天，来 Benchmark 一下试试啊？看看谁的后端吞吐量大，不多说了

我完全可以做得更好看，或者加入更多文档，但这就浪费时间了，不然花样可多了，和我家的盆栽一样多

（开个玩笑 🤣 其实 Rebase API 有现成的规划和客户端，适配起来比较方便，就是彻底规范化起来很花时间。是真的

https://github.com/duangsuse/RebaseD#%E4%B8%BA%E5%95%A5%E5%8F%88%E4%B8%8D%E5%86%99%E4%BA%86--why-archived

API 和现有的后端实现，已经项目的维护程度来说我感觉 Rebase API 还不足我依赖它... 不如自己新建一个算了 😶

明天起一个，打算增添一些分享应用的社区可能需要的功能，有：

1. 文章（Markdown）允许在标题附加 Attribute <!attribute name: value>
2. 文章添加字符串 Summary
3. 允许按照标题和 Summary 搜索文章
4. 修改部分模型的字段名字和类型
5. 去掉某些不合适的规范
6. 把顺序不正确的 API 反过来
7. 允许获取用户列表
8. 允许删除分类
9. 允许删除用户，允许搜索用户，用户可以填写 Avatar url
10. 文章可以使用修订号
11. 文章可以评论、评论可以修改和删除
12. 文章可以给自己设置别名
13. 用户可以封禁
14. 添加频率限制
15. 添加通知功能，搜藏文章更新可以提醒、手动提醒
16. 允许收藏和关注文章
17. 为文章添加更新时间线，允许清除
18. 通过 GitHub 绑定注册用户
19. 允许重置密码
20. 允许修改分类名
21. 允许转移文章所有权，为文章添加协作者
22. 使用 JWT，进行权限细分

现在就几个