Eventual Consistency in Real-time Web Apps • Hacker News Board

Re: Eventual Consistency in Real-time Web Apps

#21

Post by skrebbel » Tue, Jun 17, 2014, 7:14 PM UTC

dahjelle wrote: post #8

lucian1900 wrote: post #6

Earlier quoted context omitted.

If you have a CRDT implementation you can use on both sides, you can perform operations on the client and merge with the server correctly.

That's exactly what I'm planning on doing, as that seems to be simultaneously correct and relatively easy to program. I'm surprised, though, that I haven't found a "nicely packaged" version of some CRDTs, a server DB, and a client-side DB. I suppose it is probably because everyone's use-cases are so different and that using CRDTs limit the data you can use, to some degree.

I'm just learning about CRDTs because of this thread.

Which CRDT things did you find, did you experiment with any, which are you using and why?

Re: Eventual Consistency in Real-time Web Apps

#22

Post by aidos » Tue, Jun 17, 2014, 7:57 PM UTC

dahjelle wrote: post #14

aidos wrote: post #10

Earlier quoted context omitted.

That's great information, thank you. The paper looks really interesting - going to take a little while to get through, might start with the video :) I'd also read that it's hard to get right (I think that was in a comment on HN by one of the people who worked on wave/sharejs). In my case I've limited myself to two different flavours of small object with a limited set of fields (instead of a totally generalised system…

I've not tried it, but you might also be interested in an approach called differential synchronization[1]. Basically, it's just a specific way of passing diffs around to guarantee convergence, though (as far as I can tell) it doesn't guarantee much else (as in do you lose data if a patch can't be applied?). The really nice bits, though, are that it is a simple algorithm and that it can be applied to anything that you…

I already watched that video the other day! Didn't quite get to the end of it but I thought the general idea was interesting.

My use case is a little different, and one that OT seems to suit.

I have multiple users working on the same documents but they don't want/need to see each other's changes straight away. They perform a number of operations and then eventually save. When they save I'd like to propagate that that history to the other user(s) that haven't saved yet. It feels like OT works there - you have two threads of history and you need to rebase the uncommitted one on top of committed one.

Maybe I'm coming at the problem wrong, but it feels like something that could work quite well as a pattern in general.

Re: Eventual Consistency in Real-time Web Apps

#23

Post by skrebbel » Tue, Jun 17, 2014, 8:02 PM UTC

dahjelle wrote: post #2

Are there any "standard" models for treating a realtime web app as just another distributed database node (with, of course, extra security precautions and having to do server-side data re-validation)? I'm aware of CouchDB/PouchDB and Meteor's use of mini-Mongo client-side. Are there others?

This seems to be like the big problem of modern (web) app development. Even for not-very-realtime apps, the problem is essentially the same, and non trivial (single page web) apps I've seen end up hand-cooking some sort of sync protocol through a mixture of REST calls and maybe some websockets here and there.

I like the Couch/Pouch idea, but it's really only handy when CouchDB fits your data. You can stream all CouchDB updates to a RDBMS using the changes stream, for example when you want to easily create management information, but I don't see how you can avoid making the CouchDB bunch-of-documents-per-db concept central to the app.

I haven't looked into Meteor, but my suspicion is that due to Mongo's comparably document-oriented setup, it can't be all that different.

Re: Eventual Consistency in Real-time Web Apps

#24

Post by mcheely » Tue, Jun 17, 2014, 8:42 PM UTC

dgreensp wrote: post #7

It's a lot simpler to just have the socket, with a notification when your PUT has landed. This is what Meteor does. I don't see anything I recognize as eventual consistency in the traditional sense. It sounds like the client is just trying to receive a stream of updates, which could have been made by a single writer, and the only consistency issues are caused by the different overlapping mechanisms for getting update…

It's not always as simple as a PUT landing. Imagine you're tracking something like a phone call in real time. You want to fetch the current state of the call and start tracking it, but it's changing relatively rapidly. You also don't want to have to push the full state of the call down the notification pipe on every update, because you're handling a lot of these.

Merging the incoming deltas with fetched API state becomes a bit tricky, because you have to account for changes that might be happening while your GET is in transit. Alternatively, it may be that your notifications are slower than the GET request, depending on network conditions. An option that works in both of these cases (and doesn't involve version tagging all of your assets) is the approach described in the blog post.

Re: Eventual Consistency in Real-time Web Apps

#25

Post by dahjelle » Tue, Jun 17, 2014, 9:49 PM UTC

skrebbel wrote: post #21

dahjelle wrote: post #8

Earlier quoted context omitted.

That's exactly what I'm planning on doing, as that seems to be simultaneously correct and relatively easy to program. I'm surprised, though, that I haven't found a "nicely packaged" version of some CRDTs, a server DB, and a client-side DB. I suppose it is probably because everyone's use-cases are so different and that using CRDTs limit the data you can use, to some degree.

I'm just learning about CRDTs because of this thread. Which CRDT things did you find, did you experiment with any, which are you using and why?

(semi cross-posted from another comment)

Aral Balkan gave a talk on a CRDT called WOOT for text editing[1] that I found really helpful to get the general idea of the concept. (Really only the last 8 or 9 minutes of his talk.)

If you want more of the nitty-gritty on some of the different types of CRDT, there's fairly readable paper on the topic[2].

From there, you can start using Google Scholar to find the other papers that have been written.

[1] https://www.youtube.com/watch?v=NSTZ4mIv_wk [2] http://hal.upmc.fr/docs/00/55/55/88/PDF/techreport.pdf

Re: Eventual Consistency in Real-time Web Apps

#26

Post by mathbr » Wed, Jun 18, 2014, 11:32 AM UTC

dahjelle wrote: post #2

Are there any "standard" models for treating a realtime web app as just another distributed database node (with, of course, extra security precautions and having to do server-side data re-validation)? I'm aware of CouchDB/PouchDB and Meteor's use of mini-Mongo client-side. Are there others?

When I had to do that for some apps, the main issues were * while being offline some notifications get lost so one needs to get a sense of the general state of the central server * I wanted to synchronize only part of the database to each client (data it has the right to see) * pushes to the server could not be generic due to business logic (again, rights of the user)

Thus I started recording changes on the client, pushing them to the central server through functional endpoints and then pulling all changes from the server. To pull data from the server I found a paper[1] with an interesting way of encoding data so that the client can get a sense of the difference by getting a data structure of size proportional to the diff (no matter the whole dataset size). I developed a library for that, pretty limited for now [2].

[#2] http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p... [#1] https://github.com/3musket33rs/mathsync

Re: Eventual Consistency in Real-time Web Apps

#27

Post by jburwell » Wed, Jun 18, 2014, 3:17 PM UTC

seanmcdirmid wrote: post #4

mantraxB wrote: post #3

Earlier quoted context omitted.

Actors.

Actors says nothing about consistency; you have to do it all on your own. Basically a non solution in this area.

+1. Actors are simply a unit of concurrency and means of communication between those units. Their scope and division of labor, as well as, the associated communication protocols are left to developer. They provide no inherent consistency guarantees.