Hi folks, creator of LiveStore here (prev. founder Prisma).
Very excited to launch LiveStore in beta today after having worked on it over the past 4 years. I've built it for myself working on Overtone, an ambitious music client aiming for a native-grade high-performance app feel.
LiveStore embraces SQLite by adding a signals-based reactivity layer and combines it with event-sourced based syncing (similar to Git).
Happy to answer any question! Looking forward to thoughts and feedback!
I have evaluated the local first landscape and few solutions are as neat as this one! The only other (more mature seems to be) is tinyBase but that's based on a different model (CRDTs vs Event sourcing)
Few questions:
Would it not be possible to store and rely on larger amount of data on SQLite and keeping it on disk as an option? I see that there's a limitation of 1 GB. So maybe just a config flip to change the mode of persistence?
Also - multi-tenancy could be an interesting scenario. Think JIRA but each organisation needs their own namespace and each user/client wouldn't need all the tickets from all the organisation but only of their own (or even more scoped to department and team) therefore the local database would alway be a subset of the whole universe.
An out of the box sync server that could be run directly on Bun/Node (without Cloudflare) could be a nice addition.
But overall, really elegant solution. I like it, might give it a try in an idea I am evaluating various tools for. Unfortunately, the multi-tenancy story is critical for that.
I was just looking into LiveStore this past month for a hobby project, but it was behind a beta preview, so I hope to be able to dig in soon to see if it can be useful to me.
I love how you're pushing forward the localfirst conversation.
If you've spent any time building offline capable web apps with some sort of syncing mechanism, you begin to very quickly see the usefulness of a sync engine.
I really enjoyed the talk at Local-First Conf today — well done. I thought it was very well explained and made compelling arguments for the event-sourcing materialized into SQLite architecture.
Thank you for championing SQLite and especially OPFS Wasm SQLite on the web — we (PowerSync) are clearly also big proponents of it, so love to see other projects having success with it too.
Do you think it (in combination with React, WASM) could replace something like the Juce framework that most music apps use? I'm a beatmaker myself and would like to get into music apps but found the Juce stuff and C++ always scary.
Just saw the talk on it at Local-first Conf. So many snyc engines these days. LiveStore is exploring an interesting space in the idea maze: marrying event sourcing with sync engines.
I couldn't believe how robust LiveStore is already. I've been trying it out for a new project over the last few weeks and it's so smooth.
If so, would it run into the same issue ProseMirror-collab did as mentioned in the article? As in: A frequently updating low-latency client can lock out another high-latency client's updates.
seems you are using wa-sqlite. Can you elaborate on your strategy for persisting data offline? are you using opfs(which variant AccessHandlePoolVFS?) or indexddb? Also how are you mitigating against unstable implementation of opfs in different browsers and 7 day retention policy of safari for indexeddb?
since sqlite now also provides official wasm builds why did you decided to go with wa-sqlite?
This looks very promising but I'm a bit cautious not to fall in an hype trap.
I was experimenting with something similar for a custom local-first app with multi device support.
Would it be possible to add optional E2E encryption to this? While reading the docs, by adding encryption to the event payload you would be almost there already, even though it would prevent log compaction on the server
Totally agree re "hype trap". I'm building LiveStore for myself while working on Overtone which mostly informed the design decisions. I'm building LiveStore/Overtone to last!
> Would it be possible to add optional E2E encryption to this?
Yes, that's something that should already be possible, though I haven't done this myself yet. Happy to help if you're running into any issues.
Will definitely keep this use case in mind while working on compaction. One solution could be that only clients could do the compaction.
That's a good point. I'm in touch with the Android/Chrome team about the underlying issue.
I was hoping the underlying Android web issue would have been fixed by now (as I first noticed it ~3 years ago with some indication for progress), but looks like LiveStore needs a custom workaround for it. You can track the progress here: https://github.com/livestorejs/livestore/issues/321
I hope you understand that bridging the gaps between various levels of supported web APIs take a lot of effort and is non-trivial when building ambitious systems like LiveStore.
I’ve been working on a very similar sync problem and hit this too. I think the way forward is to use a broadcast channel to elect an individual worker that communicates with all other contexts using the broadcast channel.
This looks amazing! One small thing I noticed: I was watching the demo video on the landing page and at 1:07 your voice inexplicably pans almost completely to the left speaker - not a big deal but figured I'd apprise you of it.
Readit News
Very excited to launch LiveStore in beta today after having worked on it over the past 4 years. I've built it for myself working on Overtone, an ambitious music client aiming for a native-grade high-performance app feel.
LiveStore embraces SQLite by adding a signals-based reactivity layer and combines it with event-sourced based syncing (similar to Git).
Happy to answer any question! Looking forward to thoughts and feedback!
Few questions:
Would it not be possible to store and rely on larger amount of data on SQLite and keeping it on disk as an option? I see that there's a limitation of 1 GB. So maybe just a config flip to change the mode of persistence?
Also - multi-tenancy could be an interesting scenario. Think JIRA but each organisation needs their own namespace and each user/client wouldn't need all the tickets from all the organisation but only of their own (or even more scoped to department and team) therefore the local database would alway be a subset of the whole universe.
An out of the box sync server that could be run directly on Bun/Node (without Cloudflare) could be a nice addition.
But overall, really elegant solution. I like it, might give it a try in an idea I am evaluating various tools for. Unfortunately, the multi-tenancy story is critical for that.
[1] https://localfirst.fm/landscape
I was just looking into LiveStore this past month for a hobby project, but it was behind a beta preview, so I hope to be able to dig in soon to see if it can be useful to me.
I love how you're pushing forward the localfirst conversation.
If you've spent any time building offline capable web apps with some sort of syncing mechanism, you begin to very quickly see the usefulness of a sync engine.
Thank you for championing SQLite and especially OPFS Wasm SQLite on the web — we (PowerSync) are clearly also big proponents of it, so love to see other projects having success with it too.
Is that a requirement or could there also be federated nodes, or a full p2p modus operandus? Think for use in decentralized social networking.
I couldn't believe how robust LiveStore is already. I've been trying it out for a new project over the last few weeks and it's so smooth.
Would this fit into the "1. Serialization" strategy described here? https://mattweidner.com/2024/06/04/server-architectures.html...
If so, would it run into the same issue ProseMirror-collab did as mentioned in the article? As in: A frequently updating low-latency client can lock out another high-latency client's updates.
since sqlite now also provides official wasm builds why did you decided to go with wa-sqlite?
I was experimenting with something similar for a custom local-first app with multi device support.
Would it be possible to add optional E2E encryption to this? While reading the docs, by adding encryption to the event payload you would be almost there already, even though it would prevent log compaction on the server
> Would it be possible to add optional E2E encryption to this?
Yes, that's something that should already be possible, though I haven't done this myself yet. Happy to help if you're running into any issues.
Will definitely keep this use case in mind while working on compaction. One solution could be that only clients could do the compaction.
I was hoping the underlying Android web issue would have been fixed by now (as I first noticed it ~3 years ago with some indication for progress), but looks like LiveStore needs a custom workaround for it. You can track the progress here: https://github.com/livestorejs/livestore/issues/321
I hope you understand that bridging the gaps between various levels of supported web APIs take a lot of effort and is non-trivial when building ambitious systems like LiveStore.