Reactive Backends

58 views
Skip to first unread message

David Moshal

unread,
Jun 7, 2014, 6:58:25 PM6/7/14
to gl...@googlegroups.com
Wondering if anyone has tried to bind GluJs reactive ui to a reactive backend, eg: Firebase?

David

Michael Gai

unread,
Jun 9, 2014, 12:45:52 PM6/9/14
to gl...@googlegroups.com
Hi David:

Our current app (http://beta.conarrative.com) uses GluJS on top of Racer (https://github.com/codeparty/racer), which is in turn on top of ShareJS (https://github.com/share/ShareJS).

In our case, we use a true "MVVM" pattern, in which there is a domain model layer (that communicates with the reactive backend) distinct from the view model. We have a very sophisticated graphical application, so we needed to break down the document in the collaborative reactive model differently than how we want to compose our application UI.

The (relatively thin) model layer has a "domain event" API. It listens on changes in the shared reactive model and then raises discrete "human readable" events. For instance, our app lets you move things between containers; whereas in the document that might be represented by a 'containerId' property change, the domain model raises the event "changedContainer" and the view model behaves accordingly. Conversely, if a user moves an element between containers, the view model calls into a "relocate" event in the shared model, which then updates the reactive backend accordingly.

Admittedly that level of indirection may be overkill for many reactive back-end apps, but it has worked very well for us. It has made everything very stable even across rapid and deep changes, as we can choose at each point just to change view model/UI behavior as distinct from shared document structure.

What were you thinking about doing?

Mike

David Moshal

unread,
Jun 9, 2014, 2:15:54 PM6/9/14
to gl...@googlegroups.com
Michael, I probably need more time to digest this email, to fully
understand your architecture.

Our own application architecture (in production since 2011) looks like this:

Java backend -> Redis -> NodeJS -> Faye -> Flex (with MXML data binding)

New architecture:

Java backend -> Firebase -> Webix

(Webix chosen for the reasons outlined in the previous email).

However, because Webix has no concept of MVVM, we are developing a
layer to subscribe to firebase and look up the view components. As you
know, the code complexity increases significantly without an MVVM
pattern. Also, there is the whole coordination issue of making sure
that Dom elements before being changed! (again, obviated with MVVM
binding patterns).

So, in summary, using GluJs to bind Webix would seem to be a win.

Dave
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "GluJS" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/glujs/cGYA5kgU718/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> glujs+un...@googlegroups.com.
> To post to this group, send email to gl...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/glujs/7e4147bf-4754-4401-bbd4-d002702faa85%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages