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

41–46 of 46 posts

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

#41

Post by thruflo »

cryptonector wrote: post #40

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

On your last point: https://pglite.dev

On the main point around materialisation cost, I know more work is planned on compaction specifically but generally LiveStore is a framework that’s been highly crafted to address and optimise for all aspects of performance.

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

#42

Post by [deleted] »

jessmartin wrote: post #17
wg0 wrote: post #16

Earlier quoted context omitted.

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

[deleted]

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

#45

Post by sull »

rapnie wrote: post #29
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…

> LiveStore extends its local event-sourcing model globally by synchronizing events across all clients, typically through a central sync backend. Is that a requirement or could there also be federated nodes, or a full p2p modus operandus? Think for use in decentralized social networking.

This is what I am exploring now actually. It is feasible.

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

#46

Post by akshayKMR »

schickling wrote: post #13
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 com…

> Hope that all makes sense?

Yes! Looking forward to using Overtone.

Post reply on HN