Hi, one of the authors here. We realized that for many CRUD web apps, a library that lets you synchronize "diffsets" (lists of changes the client makes to JavaScript objects) can replace server-side controllers and views, so you don't end up doing MVC on both the server and client.
We reduced web apps to a set of authorization rules and models. You can interact with document-style objects on the client, but keep the power of relational datastores on the server.
It's a relational Firebase for CRUD apps, if you will.
Am I right that this sounds like the equivalent of an operational transformation solution that can resolve to SQL DML statements? Did you at all consider using the same wire format as something like ShareJS?
We did not consider that, but thanks, I will take a look at ShareJS. Minisync is designed only for a non-concurrent single-user use case where a user fetches a document at point A in time, makes changes, and then submits the document to the server at point B.
In this case, we intelligently resolve attribute names to SQLAlchemy mapper class instances or mapped attributes. We let SQLAlchemy do the SQL generation.
Soon, we'll open source an AngularJS plugin that lets you just push/delete from regular old JavaScript objects in order to generate the diffset the server needs. We're hoping we don't have to implement a protocol, and will instead be able to just submit a list of changes to JavaScript objects.
Ember - or Backbone, for that matter - would be a bit trickier to write a plugin for. Neither really handles hierarchal data structures in an elegant way - both have a model layer that assumes a "flat" structure, similar to server-side models.
With Angular, on the other hand, you can just pop the full object from retrieved from the server into your $scope, change it like you would any other object, and then sync it back with a function that will create a diffset between the original object and the current state.
This is very interesting. It actually strikes me as quite similar to React.js; in both cases, the mantra is "replace explicit boilerplate with an intelligent diff algorithm".
Yes, this means performance isn't as good, but does that really matter? It eliminates an entire _class_ of programming errors in one fell stroke. Higher productivity and less chance for things to go wrong? Sign me up.
6 comments
[ 5.7 ms ] story [ 40.8 ms ] threadWe reduced web apps to a set of authorization rules and models. You can interact with document-style objects on the client, but keep the power of relational datastores on the server.
It's a relational Firebase for CRUD apps, if you will.
Would love to get some feedback. Thanks!
In this case, we intelligently resolve attribute names to SQLAlchemy mapper class instances or mapped attributes. We let SQLAlchemy do the SQL generation.
Soon, we'll open source an AngularJS plugin that lets you just push/delete from regular old JavaScript objects in order to generate the diffset the server needs. We're hoping we don't have to implement a protocol, and will instead be able to just submit a list of changes to JavaScript objects.
With Angular, on the other hand, you can just pop the full object from retrieved from the server into your $scope, change it like you would any other object, and then sync it back with a function that will create a diffset between the original object and the current state.
Yes, this means performance isn't as good, but does that really matter? It eliminates an entire _class_ of programming errors in one fell stroke. Higher productivity and less chance for things to go wrong? Sign me up.