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

31–40 of 46 posts

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

#31

Post by ochiba »

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

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

#32

Post by apitman »

rramon wrote: post #20
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.

Juce is more common for music creation apps right? I believe Overtone is more of a Spotify alternative.

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

#33

Post by apitman »

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.

How is the conf going? Would have loved to attend but couldn't quite swing it. Can't wait for the videos to drop.

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

#35

Post by growthwtf »

schickling wrote: post #6
growthwtf wrote: post #5

Sounds very cool. Not impressed with the cross platform claim when the first thing I see is that android web is not supported, though.

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 th…

Very interesting context. Thank you for sharing.

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

#36

Post by wlib »

dugmartin wrote: post #30
wlib wrote: post #22

Earlier quoted context omitted.

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.

fyi, I've done something similar and the cleanest method for leader election is to use the web locks api: https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_A... 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…

That’s very elegant, thanks!

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

#37

Post by autoconfig »

schickling wrote: post #6
growthwtf wrote: post #5

Sounds very cool. Not impressed with the cross platform claim when the first thing I see is that android web is not supported, though.

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 th…

It’s beyond shameful that chrome on android doesn’t support shared workers yet. We decided to simply nix multi tab support on android because of it.

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

#38

Post by rramon »

apitman wrote: post #32
rramon wrote: post #20

Earlier quoted context omitted.

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.

Juce is more common for music creation apps right? I believe Overtone is more of a Spotify alternative.

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.

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

#40

Post by cryptonector »

I like this architecture because I like event sourcing. But you have to be careful with event sourcing. There are schemas where the views you want to materialize are slow to materialize, and anyways as the data grows the materialization gets slower. What to do? Well, the developer just has to write triggers (or equivalent) to update the materialization in-transaction, and you have to do this when doing replication / synchronization. And you need to think carefully about collision resolution -- basically you need to read up on CRDT a fair bit then think about it.

It would be really nice to have a SQLite3-like database with PG language functionality so that one could do local-first and remote-first as just a configuration setting.

Post reply on HN