Hacker News Reader

Hacker News

Comment by bob1029 | Hacker News Reader

Parent Full thread

bob1029

I agree with this sentiment. Our networks are only getting faster.

Keeping 100% of the application state in exactly one place can eliminate entire universes of problems.

If you are building an app that doesn't actually need to talk to outside things, then sure. Go 100% client-side.

The dragon is having 1 foot in each swimming pool. 50/50 state spread evenly across client & server.

View on HN

It does, but I think we no longer live in that kind of environment. Distributed is the norm, and trying to shoehorn it into a mental model where everything is all in the same place adds a kind of accidental complexity to our underlying stack for simplicity at the very top.

As an aside, with the future as a (potential) interplanetary species, networks can't beat the speed of light, so we'll have to figure this out then!

How about having the state 100% on server AND on client? No dragons, no problems.

Keeping them in sync is the dragon

How do you prevent sync issues?

One local DB/store for each app. Who is the correct sync?

Or is it first in first out?

CRDTs is how sync issues become non-issues. The “correct sync” is deterministically determined by the CRDT conflict resolution algorithm. There can be multiple DBs/stores per app or per user or per whatever makes sense. One big global DB/store broken down to millions of DBs/stores.

CRDT is the dragon slayer

It's the sword that we needed! But it doesn't take us all the way. There are semantic conflicts that are difficult for CRDTs to solve alone.

What are the semantic conflicts you mean here?

As far as I can tell, CRDTs are the correct solution for syncing state between parties.

Merge conflicts that must be resolved by the user (i.e. when there is no logical way to determine the priority of two offline changes) are still an application specific problem, even with CRDTs. You can build structures that allow storing conflict resolutions in CRDTs, but getting them right is still like half the problem to solve.

I have lack of imagination to think what kind of conflicts those would be, would you have examples?

In my experience there’s always a logical way to solve conflicts. And CRDTs can have any kind of conflict resolution algorithm, so it’s customizable per application. “Storing conflict resolutions”, eg. “a merge operation”, is not needed and unnecessarily complicates any CRDT.

Yes, sometimes it is hard to come up with the merge strategy that preserves user intent. I think the big one is rich text, where Peritext[0] looks like a good direction.

[0]: https://www.inkandswitch.com/peritext/

This is the correct answer :)

Then you get to deal with conflict resolution, which is a rare dragon that is kind of confusing and sometimes has to ask the user which state they'd like to keep.

Not if you assume the server is always right. Which is suitable for the majority of cases.

Another possibility is to assume the user is the authority and is always right. For example, if I post a tweet to my feed, I’m (or should be) the authority and always right.

Reply on news.ycombinator.com