Cumulo Workflow 项目进展

这几天在微博刷了 Woodenlist 的内容, 算是进展仍是满意的.
Woodenlist 基于我以前的 Wanderlist 作的一个小项目, 惋惜如今还没用起来.
要作到能用, 后面须要增长不少细节, 不展开了. 这里只关心技术部分.

Recollect

Woodenlist 基于 Cumulo 方案和 ClojureScript 代码, 开发使用 Stack Editor.
要更好地理解 Cumulo, 如今已经不用费口齿解释了, 直接看 Console 中的 log.
或者 WebSocket 里的数据更清晰一些, 能够看到分红两种:

• 深色的, 客户端发往服务器的数据, EDN 格式

• 浅色的, 客户端接受的数据, 其实是 Diff 结果, EDN 格式

而 Diff 内容就构成了数据同步最主要的部分, 也就是本地的 Store 的数据来源.
也就是说 Cumulo 方案目前是有缺陷的, Store 是由服务端控制的,
前端仅有组件的局部状态, 而局部状态的功能有限.

其中提到的名词不熟悉的话, 还有一些介绍, 好比 EDN 能够看文档.
而 Recollect 是我本身实现的一个 EDN 子集的 Diff/Patch 类库.
经过 Recollect 最终实现了服务端 Diff, 客户端 Patch 这个极端的方案.

Workflow

另外一个重要的部分是我将项目模板抽离出来放在仓库维护, 也就是:
https://github.com/Cumulo/cum...
好像比较早就有了, 如今主要是基于新的 Respo 和 Recollect 作了升级,
也就是说后端用 Recollect 从 DB 同步到 Store, 前端用 Respo 从 Store 同步到界面.
而 Workflow 当中就是一个可运行的 demo, 同时也做为代码模板.

此前服务端代码采用模块化的方案发布了独立的模块, 两个包,
后面考虑到项目仍是须要快速迭代, 仍是采用拷贝复用代码的方式了.
随之而来的问题升级的成本, 使用了模板的项目须要手动拷贝升级, 其实很麻烦.
但目前来讲仍是直接使用的话, 反作用的代码太多了, 抽象起来麻烦.

另外一个不小的转变是后端是 Figwheel 切换到了 Lumo 做为开发环境,
Lumo 的好处就是简单, 不用像 Figwheel 那样维护复杂的配置,
不过缺点也有, 相关的教授叫须要本身积攒, 甚至热替换须要本身制定方案,
个人文档里如今对 Lumo 尚未作妥善的说明, 因此仍是挺麻烦的.
其中一些内容我在论坛上开帖子写了, 应该是有点用的, 但也还不是文档:
http://clojure-china.org/t/lu...

整体上说, 对于 Woodenlist 这样一个最简单的 Todolist 实时应用, Cumulo 足够了.
并且开发能够作到先后端实时热替换, 这个玩法不少技术栈应该是玩不起来的.
同时我已经作到了直接用 Stack Editor 编辑远程的应用, 支持多人同时开发.
至于数据量 scale 以后的性能问题, 网络延时对体验的影响, 短时间依然不考虑.
有兴趣能够去刷刷源码 https://github.com/Cumulo/woo...

小结

进展良好, 筹码继续增长, 风险还好, 精力有点很差调整形成了一些麻烦.但如今我能作的恐怕也只有把事情作出来, 证实本身的方向是可靠的.想办法集中精力, 尽快把 Woodenlist 弄好.