Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LiveStore: State management based on reactive SQLite and built-in sync engine

livestore.dev

Post reply on HN
Print view View original

11–20 of 46 posts

Re: LiveStore: State management based on reactive SQLite and built-in sync engine

#11

Post by chrisweekly »

akshayKMR wrote: post #10

Neat to ship dev-tools alongside, looks like you've been dog-fooding this library for quite some time. What are your thoughts on: - Handling compaction for long lived apps/pages? - IMO events are nice, but also require discipline and good design w.r.t code (Thinking of how application layer evolves over time, possibility of maintaining code for older client versions and/or schema migrations. - Overtone looks sick. I'…

"sick" in the slang sense, ie "amazing / awesome"

(clarifying for non-native English readers)

Re: LiveStore: State management based on reactive SQLite and built-in sync engine

#12

Post by gbalduzzi »

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

Re: LiveStore: State management based on reactive SQLite and built-in sync engine

#13

Post by schickling »

akshayKMR wrote: post #10

Neat to ship dev-tools alongside, looks like you've been dog-fooding this library for quite some time. What are your thoughts on: - Handling compaction for long lived apps/pages? - IMO events are nice, but also require discipline and good design w.r.t code (Thinking of how application layer evolves over time, possibility of maintaining code for older client versions and/or schema migrations. - Overtone looks sick. I'…

Great questions!

> Handling compaction for long lived apps/pages?

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.

You can track the progress of this topic here: https://github.com/livestorejs/livestore/issues/254

> 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.

Hope that all makes sense?

Re: LiveStore: State management based on reactive SQLite and built-in sync engine

#14

Post by schickling »

gbalduzzi wrote: post #12

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.

Re: LiveStore: State management based on reactive SQLite and built-in sync engine

#15

Post by schickling »

jessmartin wrote: post #3

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.

Thank you! So glad you like it!

Re: LiveStore: State management based on reactive SQLite and built-in sync engine

#16

Post by wg0 »

schickling wrote: post #4

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). Hap…

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.

Re: LiveStore: State management based on reactive SQLite and built-in sync engine

#17

Post by jessmartin »

wg0 wrote: post #16
schickling wrote: post #4

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). Hap…

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…

curious: did you literally use the Local-first Landscape[1] to do the evaluation? (full disclosure: co-author of landscape)

[1] https://localfirst.fm/landscape

Re: LiveStore: State management based on reactive SQLite and built-in sync engine

#19

Post by parsadotsh »

Congrats on the launch!

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.

Re: LiveStore: State management based on reactive SQLite and built-in sync engine

#20

Post by rramon »

schickling wrote: post #4

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). Hap…

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.
Post reply on HN