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 very common question and something I'm planning to ship a solution for soon. The basic idea is to give each event some more semantic "meaning" by annotating the event definition which allows you to express which events "semantically overlap". For example in a todo app you could express that the "todoCompleted" event for a given task id can compact other "todoCompleted" / "todoUncompleted" events for the same task id.
> IMO events are nice, but also require discipline and good design w.r.t code
Yes, I agree with that. When it comes to data there is "no free lunch" - it's all about tradeoffs. I prefer the tradeoffs of event sourcing though for my own use cases such as Overtone.
That being said for many situations (like older client versions etc) there are pretty straightforward ways to address those concerns. Always depends on your application use case and possible tradeoffs though.
> Overtone looks sick. I've been using Spotify less and less because of janky UI and constant UI changes, would love a replacement. I see that it supports multiple sources, will it offer offline playback?
Very excited to hear! I'm sharing your frustrations which is why I'm building Overtone (next to many other reasons). Re "offline playback": That will depend on where your music is coming from. e.g. for your own music collection in Dropbox (or similar) it will be supported. For music streaming services like Spotify it will depend on their terms.
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.
It is supported by all browsers. You just have all the tabs try to lock the same resource and have them return a promise in the lock callback. The first one wins and when that tab closes the next one in line gets automatically elected.
The leader can then use a broadcast channel and act as a server for all the other tabs to serialize access to any shared resources.
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.
Yes already did through most of them. Either we have libraries around CRDTs or we have full BaaS (think Parse if anyone remembers or Firebase) soft of things that possibly can be self deployed but have a very heavy and iron clad curtain on the underlying storage medium (Postgres/SQLite) etc exposing a world view of their own.
tinyBase seems to be the only one that stands out in that regard or this LiveStore now.
PS: Thank you for putting this landscape. That really has enabled me or anyone else to look at what options are there. No amount of googling would do that kind of compilation. I find it very useful.
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.
Yes, Juce is used to develop DAWs and VST plugins. The way I understand it, LiveStore basically creates a client side loop in the browser comparable to apps you would install and run locally on your device. Having the data (e.g. samples) stored in sqlite within the client side loop would make a huge difference vs. web apps fetching and caching from a backend I assume.
Hey everyone, host of the localfirst.fm podcast here (and previously founder of Prisma).
In collaboration with Jess Martin, we've been working on the Local-First Landscape resources which provides an overview and comparison of various local-first technologies. It's meant to provide orientation to people new to local-first app development.
We hope this is useful and welcome any form of feedback and suggestions! Thank you!
