Mobx-state-tree: Firebase interoperability

[adonis-work]

Firebase is a real-time database that connects to your browser via web sockets. It keeps data in sync by updating local data in real time as data changes on the server and vice versa, updates itself and all other users as soon as you submit a change.

I wonder if mobx-state-tree could be used as a local representation of the Firebase database to have multiple mobx-state-trees kept in sync over the web?

This state would be stored online in real time in Firebase, which would enable the app to simply shut down at any time on any computer and later wake up on any computer to continue where you left off the last time you closed it.

Worst case scenario: could a dump of the current database tree over* the active mobx-state-tree be performed with as little cpu usage as possible (similar to dom diffing) or would the whole tree needed to be rebuilt?

_*for example: if you listen only to the root of the Firebase db for changes you'll receive a new copy of the whole database tree when there is an update to one leaf node_

[mweststrate]

See the boxes example; it syncs over websockets. https://github.com/mobxjs/mobx-state-tree/blob/master/examples/boxes/src/stores/socket.js

In mobx-state-tree you could even opt for 3 different strategies in this regard (by commenting in that file you can switch strategies):

1. sync complete snapshots (expensive)
2. sync json patches (distribute data diffs)
3. sync action invocations (distribute user intentions)

[RainerAtSpirit]

Listen only to the root of Firbase... you'll receive a new copy the whole database tree

doesn't sound practically on larger data sets.

I'd recommend looking into 3. That makes firebase the leading system the rest would simply follow.

[nbostrom]

There's actually one benefit of syncing actions over syncing diffs. Actions can be "thread safe". Let me give you an example. Let's say that we are building a counter app. The state looks like this:

{ count: 0 }

Two clients, A and B are using the app simultaneously.

1. A increments the counter once.
2. B increments the counter before receiving the data from A.
3. B receives the data from A.

With patches the events would produce this:

1. A produces a patch {op: 'replace', path: 'count', value: 1}.
2. B produces a patch {op: 'replace', path: 'count', value: 1}.
3. B receives the patch from A. The state will not change, count was already 1.

With actions the events could produce this:

1. A produces and action {type: INCREMENT_COUNTER}
2. B produces and action {type: INCREMENT_COUNTER}
3. B receives action from A {type: INCREMENT_COUNTER}
count is now 2! Yay!

I tried to build something similar with patches over a gossip protocol to sync immutable structures before, but soon realized that actions are the way to go. There are too many edge cases with patches.

[RainerAtSpirit]

A and B in your example wouldn't communicate directly when using firebase, both would communicate with firebase, correct? In that case you would have to solve concurrency in the central place by using e.g. transactions.
https://firebase.google.com/docs/database/web/read-and-write#save_data_as_transactions

[nbostrom]

Nice! I did not know that firebase solved these problems :)
Anyhow. This is something to think about when doing other integrations I guess. Maybe not relevant to this issue though, it seems. I just wanted to point out the difference. I guess that MST could solve this internally by introducing additional ops in patches, but that is another issue.

[johndevor]

I'm trying to figure out which one of these would make more sense.

• User makes an edit. Edit is posted as a transaction to firebase. MST receives notification of change and updates it's structure (from an observing call back) and UI updates.

• User makes an edit. MST receives edit via an action. Middleware intercepts the action and then updates firebase. Other users update their MST through a callback.

In the first case, there really would be no need to use MST actions if I'm understanding this correctly. Seems to me like there is some duplication here with actions and transactions.

[adonis-work]

Firebase is simulating the server's event (on add, on delete...) even when you submit your own change to the server. This way you are getting back your fresh update each time from the server even if you do not have an internet connection at the moment (it will sync missed changes when you get your connection back).

Imho the MST should capture data updates at those change events (simulated or real, from the Firebase), this would also work nicely with the automatic sync when internet connection gets restored.

But... if the latter is also achievable by using MobX while simplifying the process, would using MST have any advantage over it?

[pdemilly]

I am interested in knowing more about integrating mobx-state-tree with firebase so that a view can be concurrently edited by more than 1 user session. Is there any examples existing?

[johndevor]

Me too!

On Fri, Sep 15, 2017, 11:26 AM Pascal DeMilly [e-mail]
wrote:

I am interested in knowing more about integrating mobx-state-tree with
firebase so that a view can be concurrently edited by more than 1 user
session. Is there any examples existing?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx-state-tree/issues/116#issuecomment-329815544,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEoM7KAMtvz9iTmCCjaaZkAmB_8HHtAks5sipc8gaJpZM4NUUtw
.

[mattiamanzati]

GeekyAnts has worked on this, you can check it out here: https://github.com/GeekyAnts/mobx-state-tree-firebase