schickling

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.

Thank you! So glad you like it!

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.

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?

Thanks for sharing this episode. Planning to do a dedicated episode about LiveStore some time soon. :)

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!

Podcast host here. Thanks so much for your kind words! Glad to hear you're enjoying the conversations and find them helpful!

We're still working on it! We'll hopefully have more to share soon!

In the meanwhile you might like this talk by Geoffrey: https://www.youtube.com/watch?v=zjl7CpG9h3w&pp=ygUNZ2VvZmZyZ...

I’ve been using Tauri for about a year now and couldn’t be more excited for it to reach 1.0

Looking forward to a new generation of desktop (and even mobile) apps!

Yes and besides this mentioned M1 problem, it's been really great to use. I think Tauri has a lot of potential!

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.

Almost all developers/team who actually tried out and used GraphQL, will say the same thing: You never want to go back.

Most of the arguments against GraphQL that I'm reading here, seem to actually be misconceptions (or the GraphQL ecosystem not being far enough yet).

This is a fantastic point!

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.

Hi jmandzik, I'd be very interested to learn more about your project. What's the best way to get in touch?

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.

Check out this article for some more details: https://blog.graph.cool/reusing-composing-graphql-apis-with-...

I 100% agree with what Benjie said. With things like schema stitching (see https://blog.graph.cool/graphql-schema-stitching-explained-s...) it's getting super simple to compose GraphQL APIs and therefore use PostGraphile as a "GraphQL database".

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

If you're interested, this blog post further describes these concepts: https://blog.graph.cool/reusing-composing-graphql-apis-with-...

Thanks a lot for the mention, Benjie!

optimuspaul, I'd be very interested in learning more about your project, as this is something we're looking into as part of our roadmap. Would be great to have a chat in our Slack: https://slack.graph.cool/

I'm very much looking forward to the Next.js-like framework you've teasered!

This looks amazing! Is there some demo video available?

While there are a couple of similar elements (you can rudimentary read and write data), the use case AppSync is trying to tackle is very different. It's main use case is not to act as the core of your application but rather as a wrapper around various AWS data sources.

There's a new concept called schema stitching which enables you to combine (and re-expose) GraphQL APIs which will make it possible to build a simple server that stitches together both Graphcool (as your primary data backend) and AppSync to easily access other information stored in AWS services. (You can read more about schema stitching here: https://www.advancedgraphql.com/content/schema-stitching)

Thanks a great point, avitzurel! This will be exactly one of the core offerings what we're currently working on at Graphcool.

AWS provides great building blocks but using them efficiently is a major challenge (especially for smaller teams). Like in your case, there is an enormous potential in better resource utilization!

Thanks for sharing these resources! Regarding your last point stating that "these technologies are at least a great way to prototype a backend.":

We've taken this feedback extremely seriously and are extracting the core of Graphcool as a standalone component which is a "GraphQL database". While it's not as user friendly (as of a visual user interface) it's meant as a foundation for highly scalable systems (based on the architectures you might find at Twitter or Facebook).

I'm very happy to hear more of your concerns and answer any questions!

Hi obilgic, thanks a lot for the shout out!

This is a super exciting announcement from the side of AWS which is really well aligned with some of our upcoming product changes. Expect some news in the next couple of weeks!

Hi, co-founder of Graphcool here. It's very exciting to see AWS adopting GraphQL as a part of their offering. GraphQL in combination with serverless functions is a great fit to build applications quickly and shines in the use case described by AppSync.

P.S. We'll soon release a few example of how to use AppSync together with Graphcool (which works really well together!)

Which features are you missing in GraphQL's type system?

You can use the Star Wars API: http://swapi.graph.cool/