FWIW, I think you might be better off with immutable rows and lamport clocks.
Everything is a full new row because it is “a message” including read receipts. Some messages like read receipts just don’t render in the chat.
Edits can work the same way by rendering over a previous message, even though the local and remote DB have multiple rows for the original and edited messages.
boris · 54m ago
> And because Electric syncs every change granularly, you are certain that the state of your local database is exactly the same as the server's.
I don't see how this certainty follows from "granularity" (whatever that means in this context). I believe to have such a certainty one would need the synchronization to happen within a single transaction that spans both client and server databases.
ethan_smith · 3m ago
Correct - granular syncing alone doesn't guarantee consistency; you'd need either a distributed transaction protocol or a conflict resolution strategy with eventual consistency semantics.
judge123 · 55m ago
It feels like everyone is solving the sync problem from a slightly different angle. Has anyone here used a few of these in production?
Thanks for sharing this talk. I didn’t know about MobX, but I did use your fork of wa-sqlite (https://github.com/team-reflect/wa-sqlite/) since I also needed the sqlite-vec extension :)
By the way, Reflect is an awesome app; I'm actually a paid subscriber.
Jarwain · 1h ago
I love the timing of how, over the past week or so I've been digging into the ecosystem and options around this, and now here's another article!
gczh · 2h ago
very cool! have you tried Tanstack DB and ElectricSQL?
The whole line of Tanstack products is very well made yet poorly designed at the same time. I don't know if it's inherited from React by trying (and succeeding) to be a seamless React experience or if it's part of their own philosophy, but most of the tools make it very easy to mix state everywhere in your app which is just bad.
Really people should just move to Gleam and Lustre or Elm, even if it means I'll have much fewer clients paying good money to untangle state issues...
robinfaraj · 2h ago
very cool stuff!
st-keller · 46m ago
Ok is this about a reactive app with with a local database automatically synced to a remote db? All fully encrypted (at rest and in transit)?
I thought this is what everyone does nowadays!
We built an app like this in 2019 - yes - it was a bit of a challenge with the encryption but the „syncing data“-part is what every litte multiplayer-game has to deal with like forever now. Seems i‘m out of touch with the current state of affairs.
Nice article though!
JSR_FDED · 11m ago
The value is in the author’s experience with other tools that caused problems as his database grew, and in learning from his reasoning about the appropriate solution for his particular problem.
Everything is a full new row because it is “a message” including read receipts. Some messages like read receipts just don’t render in the chat.
Edits can work the same way by rendering over a previous message, even though the local and remote DB have multiple rows for the original and edited messages.
I don't see how this certainty follows from "granularity" (whatever that means in this context). I believe to have such a certainty one would need the synchronization to happen within a single transaction that spans both client and server databases.
Using the wa-sqlite library, and our own Mobx-based model layer similar to what Linear does.
I gave a short talk about it a few months ago https://www.youtube.com/watch?v=b0GKWzeyZko
https://x.com/marcelohbairros/status/1956892684859158892
Really people should just move to Gleam and Lustre or Elm, even if it means I'll have much fewer clients paying good money to untangle state issues...