The author links to a much longer post on handling conflicts which is worthy of its length because it's not a pleasant experience with this setup.

I highly recommend trying a modern setup from one of the many new local first solutions [2]

1. https://triplit.dev

2. https://www.localfirst.fm/landscape

Comments URL: https://news.ycombinator.com/item?id=43772223

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=43727351

Points: 2

# Comments: 0

That's basically what we're doing with Triplit (https://triplit.dev), be it, not with SQL--which is a plus for most developers.

Comments URL: https://news.ycombinator.com/item?id=43262212

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=42629793

Points: 3

# Comments: 0

0. https://www.triplit.dev/docs/frameworks/react-native

It's often times fine on iOS and then incredibly slow on Android. Hermes is very exciting but still requires many polyfills to make simple NPM packages work. I hope one day, the web (and embedding web apps on mobile) makes React Native fully obsolete.

Docs for it: https://www.triplit.dev/docs/frameworks/tanstack-router#exam...

It by default uses IndexedDB but can also use SQLite but does real time, relational querying and (optionally) syncs with you server.

Re: developer ergonomics, this is our primary focus so I don't love to get your feedback on!

The other issue of relying on a just the server to build these highly collaborative apps is you can't wait for a roundtrip to the server for each interaction if you want it to feel fast. Sure you can for those rare cases where your user is on a stable Wifi network, on a fast connection, and near their data; however, a lot computing is now on mobile where pings are much much higher than 10ms and on top of that when you have two people collaborating from different regions, someone will be too far away to rely on round trips.

Ultimately, you're going to need a client caching component (at least optimistic mutations) so you can either lean into that or try to create a complicated mess where all of your logic needs to be duplicated in the frontend and backend (potentially in different programming languages!).

The best approach IMO (again biased to what Triplit does) is to have the same query engine on both client and server so the exact query you use to get data from your central server can also be used to resolve from the clients cache.

https://triplit.dev

I've stated before that I think the main thing holding back collaborative text / sequence CRDTs is integration with a production database.

Eg-walker looks interesting because it might lend itself to be integrated into a database because the operations are immutable and only appended. However, to demonstrate the effectiveness of these algorithms library authors (see Yjs, DiamondTypes, etc) build stand-alone data structures (usually specialized search trees) that most databases already provide.

Personally, I've been trying to adapt a Piece Table[1] to be collaborative and stored in Triplit[2] which runs on both client and server and already implements logical clocks but I might see how well I can adapt this algorithm instead!

1. https://en.wikipedia.org/wiki/Piece_table 2. https://github.com/aspen-cloud/triplit

Comments URL: https://news.ycombinator.com/item?id=41524598

Points: 4

# Comments: 0

Personally, I much prefer developing for the web than native so if there were APIs exclusive to Ladybird it might create a nice virtuous cycle of developers targeting Ladybird to do new things and users using Ladybird to try those new experiences.

Comments URL: https://news.ycombinator.com/item?id=40847693

Points: 3

# Comments: 0

on self-hosting: We're cleaning up the docs on self-hosting to make the configuration clearer, thanks for point that out.

on querying: Yeah we don't have aggregations yet but it's on our roadmap. Don't want to over promise but I think we can make something awesome here by leverage our incremental querying engine. Like consider a data dashboard that needs to be updated every hour; in a traditional system (postgres, mongo, etc) you would need to rerun the query from scratch each time. Our plan is to create something closer to what Materialize does and just process the new data so it's much more efficient and can just update continuously rather than every hour.

re Evolu: I haven't actually gotten a change to try it out but there might be in someone in our Discord[1] that has that could compare/contrast

1. https://triplit.dev/discord