如果开发一个云笔记应该怎么设计?

[cond0r]

如果做一个支持协同编辑,文档共享,类似 yuque 那样的 应该怎么技术选型?

自己做了一款 web 的笔记软件,目录树结构,markdown 格式存储,支持协同编辑和公开分享(单页),遇到一些问题,

想请教一下各位

目前用 go 写的,协同用的 websockets 进行广播,存储用的 mysql,搜索索引用的 bleve

数据库的设计比较简单

notes 表除了常规的内容存储,加了一个ParentId来存储上级节点的 ID 来实现的无限下级

第一个问题是是权限问题

但是无法解决权限问题,比如我创建了一篇笔记本下面有 N 篇子笔记

我把笔记本分享给了 A,A 在下面又创建了 N 个子笔记,这玩意权限应该怎么管控

现在比较蠢,笔记 ID 用的 UUID,保证唯一性不能被遍历导致越权修改,

在通过笔记绑定 UID,设置只能由拥有者进行删除 /移动操作.

实际上如果知道其他人的笔记的 UUID 就能进行读取了..

目前协作编辑,实际上就是把分享的 UUID 共享给目标用户,这样他就能通过这个 UUID 来遍及下级节点进行编辑了.

想过用中间表来管理每一篇笔记的权限,但是感觉如果并发高是不是性能会差一点,虽然可以用缓存等方式解决

权限问题 2

就是公开分享,目前只能分享单页,也是因为上面的问题不好做权限管理,如果分享了 A 笔记本,下面有 1 万篇子笔记

如果用中间表势必要创建 1 万个权限表的数据..

第二个问题是双向链

如果想实现类似 obsidian 之类的双向链接功能

是不是要把文章拆分成 block

然后用一个中间表来管理 block 的类型和链接

第三个问题是数据库

现在用的绑定到编辑器的 onchange 事件,如果发生变化就更新,但是如果并发比较高的话感觉性能是个很大的问题,加上会有一些 api 会做一些比较多的实时写入,感觉 mysql 不是很好的选择

是不是用 mongo 会更好,但是现在用 gorm 做的绑定用起来确实方便,改成 mongo 感觉大部分数据库部分都得手撸语句.

[FrankAdler]

不建议 mongo ，典型的关系型数据，性能问题解决方案应该挺多的。
权限我感觉你可以想的简单点，每篇内容都是独立的，那权限也就是独立的，所谓的子内容不过是一个标记，到了展示层面排序锊好就行了，很单纯的树状数据，很多好的解决方案。
双向链笔记没用过不清楚场景不做评价。

[cond0r]

@FrankAdler #1 我明白每篇笔记都是独立的,但是如果单用户使用没啥问题,就是如果我父笔记下有 1w 篇子笔记,
那么我在把父笔记增加协作用户的时候 ,同时就要给下面的 1w 篇子笔记创建权限分配,但是如果笔记量更大,用户更多的时候感觉这个权限表就炸了..

[FrankAdler]

@cond0r 你子笔记需要继承权限吗，笔记不同于其他的场景，没必要继承吧，如果真要继承那你自己衡量向上查和单独记的成本

[cond0r]

@FrankAdler #3 目前就是不继承,但是不继承的话就会存在越权访问,如果继承的话 在协作场景里面就会存在在 N 个子笔记里面创建了新的,要回溯到上级 N 层找到共享的层级来绑定权限..

[FrankAdler]

@cond0r 越权是因为要展示层级关系导致的吗，这个可以通过去掉层级规避吗