Open Sourcing of dxData
- Reactivity: Changes in server data are reflected immediately on the client without an app developer needing to do special work.
- Unidirectionality: The data "source of truth" is to be found on the server. Changes to that data go through the server (the client doesn't try to anticipate the state of the server)
- Common types: The data and operations communicated between client and server are defined in a language neutral form that assures that both the client and the server code is always in lockstep agreement, preventing code from inadvertently diverging, and helping to support the previous two principles.
This project includes not only the client library, but also a full demo application (both client and server) that demonstrates using it and some of the key ideas it embodies.
At the heart of dxData are a set of JSON schemas that describe data types being shared between the client and server. The dxData system automatically configures itself based on whatever type definitions you feed it. You can instantiate a dxData system easily:
This will process the schemas and attach the necessary access functions to myData. Thereafter myData is intimately familiar with the data types defined in MY_SCHEMAS. With this done, you can then easily retrieve an object from the server:
dxData is built on top of Backbone, so the objects returned from the server are returned as Backbone models. This gives you the ability to set up change handlers on those models. For example, the following example will update the user name on the screen any time the user object changes.
How does the client know when to get an update to the user object from the server? The beautiful thing about the dxData system is that the client doesn't need to know. Whenever the user object is changed on the server the reactive dxData system automatically notices, retrieves the new value and updates the Backbone-based model behind the scenes. The developer doesn't need to do any work. It is also possible to call operations on the server through these objects. For example, if you wanted to disable the user represented by the above object, you can simply say:
While this looks like any ordinary function call, it actually sends a request to the server to issue the disable operation on this user object. Behind the scenes, of course, this is issuing an HTTP request to a REST-ful API. However, as an application developer, you are entirely shielded from needing to worry about HTTP, URL's and JSON. You just work with an always up-to-date object-oriented version of your server data.
Through these couple examples, you can see the unidirectionality of the system. The server always has the true version of the important data. All changes to those happen on the server, and the results flow from the server to the client. This, of course, makes it much easier to understand the state of the system. There is, of course, a lot more to the dxData system than I can summarize here.
Fork it at it and try it out. We welcome your ideas and improvements (and get your name added to the long list of folks who made it what it is now)!