Anybody give much thought to client-side data-binding these days?
OrientDB is nearing version 1.0, and it has a native HTTP/JSON interface – it supports classes, inheritance and all kinds of relationships, all the things we try to simulate with object-relational mappers when building a domain-model, which makes me wonder… why use an ORM at all?
If you’re going to do all your data-binding on the client-side, and if a graph database can natively represent your domain-model without a line of code, why struggle to achieve the same thing with server-side code and object-relational mapping?
You’d only need controllers/actions for actual business-operations. You could probably implement a thin “proxy” for operations like updates and deletes, access control and user identity, etc… You would never need to render a template, generate tables or forms or parse a form-post or implement tedious CRUD operations on the server-side.
It all sounds dreamy, and I can see this working out great for applications.
But what about SEO? The internet lives and breathes HTML. So it seems it’s not an approach that will work for public-facing pages.
Any thoughts? 
Your thoughts are the same of mine. Can a modern Web application be 100% client side? What about security? What about SEO? What about development time?
There’s a new project, temporary called “OrientWEB”, totally based on OrientDB as backend that binds the JSON returned by the GraphDB into the HTML form and vice-versa following some conventions.
The lib takes care to get all the changes happened at client-side, build a new JSON and send it back to OrientDB. The GraphDB will save only the delta of changes.
Even if this kind of approach is quite novel seems the right direction to build really scalable applications where the rendering time of pages is moved from the server to the clients. This means that each client makes own job unloading the central server(s) of this costly operation.
Lvc@
Thanks for your comments, Luca!
One thought I’ve been kicking around since I started thinking about this, is why would you need to bind against JSON? Another format could work – why not simply HTML5?
You could sprinkle search-engine friendly HTML-”serialized” (and formatted) data with parser-friendly data-attributes. Search engines would be able to index the content, and (assuming the serialization-format is fully normalized and consistent) a client-side parser could extract data from the same content.
That’s an idea I’ve been playing with for a while… Maybe it’s time to stop thinking and prototype something…
Hi Rasmus,
I do believe this is the best way to build web application nowadays.
JavaScript engines are so powerful we can keep state on the client side, giving to the user a much more responsive and improved experience. Moving the state on the client side is not a simple task though. It requires re-thinking of templating, data structures, communication to the server and much more.
I am currently developing a web application that uses backbone.js on the client side and talks to the server sending and receiving JSON objects through RESTful web services. On the server side I just read/store the JSON into an OrientDB.
Comparing with the old server-side approach I have speed-up the dev time and the user experience has been improved drastically. In my case the SEO is not a problem so I don’t have any drawback choosing this approach.
Fabrizio
Fabrizio,
have you planned to release something? Could it be interesting merging pieces of code in a unique client-side library?
Lvc@
Hi Luca,
I am working on SaaS application that will be released between next June and July. Every customer will have a separate OrientDB.
The front-end is 100% HTML5 / Javascript (with jquery + backbone) application. It would be great to share our experience to figure out if the client-side part can be merged to obtain a reusable library.
Cheers,
Fabrizio
Fabrizio,
I would love to see that – if/when there’s a blog post (or even code) please post a link here!
Thanks