3 way data-binding is a dangerous way to manage shared state. It is fine for very small apps or where state is not mission critical, but is a very dangerous pattern if you are trying to sync critical business data between many users. There are just too many situations that conflicts can emerge if it isn’t a chat app.
I would encourage you to look into functional reactive programming. It isn’t a language, but it is a very smart design pattern. You can have a real-time, reactive front end that looks great and uses websockets to move state over the network, but not just let socket.io or firebase be in charge of sorting out the details.
It means that state (data) moves through your app in one direction between the server, client, or peers. Imagine building your app like a marble tower. Each piece of the tower does some function on the marble, but the marble always moves the same direction: eventually down. If you were to model the marble’s position with data, a FRP app might log events when the marble enters or exits each functional piece and transmit that data via websocks to over marble towers. Clean. Imagine that marblePosition() was shared via 3 way data binding. The marble’s position would have to stay in-sync across a central database and each peer. If there was a network transport issue on one marble tower, then it came back online, the marble on the first tower may jump back 3 pieces because it got a message from the second tower that position should be where it went offline. Messy. This is a terrible example, but I hope you get the idea.
I highly recommend spending some time over here: https://github.com/Day8/re-frame
Also, It is VERY possible to do FRP with dreamfactory. Just make the client subscribe to state data where it needs to and create new state where it needs to, strongly separating your code so that user interactions and displays to the user of data are two different ends of the same path, not trying to sync up. There is nothing right or wrong about MVVM or 3 way data binding, but it is not for every use case. Think of an old-school arcade game: There is a monitor and controls. There is no data binding. As soon as a quarter is inserted, the demo loop is interrupted and the new game screen is launched. When the player users the controls, they send state data to some device that tells something else what to do next, and eventually the screen shows something new to the player. Its FAST. and it doesn’t break, or if it does you know where very quickly.
Also, if you insist on using 3 way databinding you can do so via REST API w/ firebase or socket.io.
That is all. Correct me if I am wrong, everybody!