Host of localfirst.fm and author of LiveStore here. Your post strongly resonates and I particularly like your conclusion in regards to SQLite.
I've been exploring how to build a sync layer around SQLite for the last 5 years as part of LiveStore and settled on embracing event sourcing following a similar architecture to Git but for your application data.
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.
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!
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!
I'm excited to hear you're looking into this and take it serious. I think this is a great opportunity to for the Tauri community to become a more welcoming and inclusive place. Happy to help!
Hi folks, I'm the user from the screenshot above (thanks for sharing this btw).
I have to say, this was a quite unpleasant and unwelcoming interaction as my question was genuine and I indeed did do some extensive research before asking this question in Discord.
As a devtools founder myself (co-founded www.prisma.io) I highly value welcoming and helpful communities and offered my help to the people behind the Tauri project to turn it into a more welcoming community. I hope they are open to it since I actually really enjoy using Tauri as a project.
Co-creator of How to GraphQL here. I’m very excited to tell you that we’re currently working on a new iteration of the page and content that will include more in-depth chapters about dataloaders, authentication, authorization and other advanced topics.
Would be great to hear more thoughts on which topics you’d like to see covered.
GraphQL is finally an API standard that strikes the right balance between simplicity and flexibility and has the potential to be the only query language most developers have to learn – and could therefore fulfil the idea of ODBC.
In regards to other SQL databases, we're currently working on a GraphQL database proxy that turns your database into a GraphQL API. We're starting with MySQL but have other databases like PostgraphQL, SQL Server, Oracle, DynamoDB on the way.
Yes, this simply runs in the same Node.js process (or any other programming language really) and doesn't add any complexity. Under the hood it's simply delegating your GraphQL queries to another GraphQL API (e.g. PostGraphile or Graphcool) – think of this as a smart HTTP request forwarder.
In terms of the API you're using, you can either use a "dynamic" GraphQL binding which uses method introspection (e.g. via JS proxies) or a generated "static" GraphQL binding which maps the GraphQL type system to your programming language. This way you can catch errors at build/compile time and get auto-completion functionality like in GraphiQL/Playground.
Static GraphQL bindings even allow to take this even a step further by mapping the GraphQL API capabilities to your (typed) programming language. This kind of gives you a typed "GraphQL ORM" without the typical downsides of a ORM (performance, API limitations etc).
I've been exploring how to build a sync layer around SQLite for the last 5 years as part of LiveStore and settled on embracing event sourcing following a similar architecture to Git but for your application data.