Decide on a realtime backend

[AlecAivazis]

One that comes to mind immediately is google's realtime api. This seems to already do a lot most of what we would need but it might be challenging to integrate it into a component. I haven't looked too closely but assuming they let us provide callbacks, we shouldn't have too much trouble.

We could also do a normal socket.io setup but we would have to do the state merges ourselves. There are some packages which implement the same OT algorithm that google docs uses which might be worth considering at least.

I also read about some people basing a real time editor on firebase but I haven't use them before so I'm not sure how that would look.

[chauthai]

Google's realtime api sounds pretty straight forward to use and the results should be nice.
But I would really like to explore other possibilities.

My suggestion is to use pouchdb which would take care of the state syncs for us. A very detailed explaination of the architecture using redux and example implementations can be found here.

We could reuse a lot of the redux-middleware and server implementations and concentrate on integrating draft.js and user authentication.

[AlecAivazis]

So user authentication is really the only part of the pouchdb setup that I'm unclear about but I'm sure that will sort itself out. Unless anyone else has a reason against it, I'm all for trying to use pouchdb

[AlecAivazis]

Thanks for the great links, they really helped illuminate some confusion for me.

[chauthai]

@RaitoBezarius @zyzo what's your opinion on the topic?

Digging into OT I've found 2 alternatives: Differential Synchronization and CRDT.

I still don't know which type of sync and conflict resolution pouchdb uses.

[RaitoBezarius]

Could I suggest looking into RethinkDB ?
I'm fairly accustomed and I believe that they are a very good option for
realtime.

On Wed, Feb 24, 2016, 12:26 Chau Thai notifications@github.com wrote:

@RaitoBezarius https://github.com/RaitoBezarius @zyzo
https://github.com/zyzo what's your opinion on the topic?

Digging into OT https://en.wikipedia.org/wiki/Operational_transformation
I've found 2 alternatives: Differential Synchronization
https://neil.fraser.name/writing/sync/ and CRDT
https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type.

I still don't know which type of sync and conflict resolution pouchdb
uses.

—
Reply to this email directly or view it on GitHub
#1 (comment)
.

Ryan Lahfa, de mon téléphone.

[chauthai]

@RaitoBezarius RethinkDB doesn't support offline mode yet. The only option is to dump a backup when you go offline.

[RaitoBezarius]

@chauthai Hmmm, you're definitely right. (My guts would argue to say: let's build offline mode on top of RethinkDB then! 😄 but alright).

In this case, let's stick to PouchDB, I imagine that for this project, we should not think too much on how it is done, but what are the drawbacks / advantages of the technology?

So we can iterate on the idea and see where does it take us. So my question is:

Does PouchDB is the good choice to reconcile our data if there is conflict?

(Note: It sounds we're doing like React does with the DOM -- except we're reconciling two documents, could we learn something from what they learnt doing reconcilation?)

[chauthai]

@RaitoBezarius Hehe, yeah I would really like to add offline functionality to RethinkDB 😃 ...

Does PouchDB is the good choice to reconcile our data if there is conflict?

Reading through the conflict guide, I think the best solution for our use case is to use the Accountants don't use erasers strategy.
For every change of the document a new version will be created, there is no mutable document in the db. It reminds me a lot of immutable.js, that is already implemented in draft.js. You will even get the redo/undo functionality for free.
In the first step that should already solve a lot of conflict problems. The first major problem I can find with this strategy is:

What happens when two clients use the same timestamp as the id in a new version of the document like in the example of the guide?

There is already an implementation of the strategy for PouchDB called delta-pouch.