Open steida opened 1 year ago
My goal is to have CRDT that is fast but not black box. Evolu prefers simplicity. Everyone should be able to read the code and understand how it works. I watch what other developers do, and I want to learn from their mistakes. The current implementation could be better, but it works well. And we will improve it. There are several hyper-optimized CRDT... black boxes. Rust makes code inaccessible, and it's not a good trade-off. JavaScript is fast enough and will be even faster with Static Hermes.
As for Kysely. Let's wait https://github.com/kysely-org/kysely/pull/218#issuecomment-1304519259
Consider replacing Merkle Trie with Range-Based Set Reconciliation
Use optimizations similar to Automerge and Negentropy to save bandwidth
Another idea is to hold the clock, Merkle tree, and table definitions in tab memory to skip reads, but it's unfortunately impossible because inactive tabs would have to be updated in the background, and such an async operation can't be reliable, AFAIK.We can already do that because we have one DB instance per many tabs.For m:n relations, consider https://github.com/ccorcos/tuple-database#Motivation as an additional abstraction. SQL has to be always supported because that's what people use and know. The core idea of a tuple database is to build indexes by queries; I think Evolu can do that, too, because it does not expose mutation SQLite API.
IMHO unnecessary