search

chauthai / realtime-draft

A google docs clone powered by Facebook's Draft framework
4 stars 0 forks source link

Decide on a realtime backend #1

Open AlecAivazis opened 8 years ago

AlecAivazis commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

chauthai commented 8 years ago

@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 commented 8 years ago

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 https://github.com/aaivazis/realtime-draft/issues/1#issuecomment-188206052 .

Ryan Lahfa, de mon téléphone.

chauthai commented 8 years ago

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

RaitoBezarius commented 8 years ago

@chauthai Hmmm, you're definitely right. (My guts would argue to say: let's build offline mode on top of RethinkDB then! :smile: 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 commented 8 years ago

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

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.