That is a boring bunch of words. Here is why it is interesting.
Typical enterprise web-application architectures that I've worked on in the past look something like this:
The grey boxes represent the data format used between each layer. As you can see, the data gets transformed many times in a typical web request from Database to Browser.
Ok now let's have some fun.
Imagine that our database was clever enough to do all of our form validation and authentication for us. Our diagram would change to look like this:
And what about if we split up the application layer - we can put all of our business validation logic in database, and push any other leftover application logic into the presentation layer.
As shown in the diagram, there are typically two methods used to produce HTML, and they are often used together:
1. Server side view templating - where HTML code is produced on the server and sent directly to the browser (e.g. server side MVC, JSP, Velocity, Freemarker)
2. AJAX - where only data is sent from the server via an XMLHttpRequest, and Javascript manipulates the DOM directly
Let's abandon server-side templating, and do all our templating on the client side in Javascript. In fact, let's use Javascript for all our presentation needs:
Then how about we give our Database an HTTP interface, make it speak JSON and store data in JSON format. This will allow us to remove the data access layer and that awful ORM to which we've been shackled for so long.
What kind of amazing magical database can do all this? Well it turns out that a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API can.
I'm not claiming any silver bullet here, in fact CouchDB is still relatively immature. But as a potential architecture for a typical Enterprise Web App - it makes you think about whether we really need all of those grey and blue boxes.
If you'd like to learn more - download CouchDB, try CouchApp, and try this demo.
Oh and as promised - here are some kittens:
6 comments:
As long as validation logic is declarative and we don´t end with stuff like PL/SQL driven systems (like Oracle Forms), It seems quite interesting.
Just seeing that model itself is exciting as a web app developer, but I am curious how secure is it to expose a newish database like CouchDB to the user side. All JS is client side and that might also mean enabling a nifty end-user to manipulate the application logic.
This may work best in a closed environment with good usage oversight, but to build a web scale application may not be feasible as of right now.
You're right, security needs to be considered.
I didn't go into detail in this post, but Couchdb itself has validation functions to protect your data.
End-users can manipulate the application logic as much as they want. But that is ok! Database edits are validated, authenticated and authorised by couchDB, and that is the beauty of this architecture.
It enables true separation of concerns, putting business validation close to the data on the server side and all other application and presentation logic onto the client side, where it belongs.
Yeah I read up on the basics for validation. Do I have to use some middleware like sammy.js or is the purist architecture realistically feasible?
Hehe, That word 'middleware' sends shivers up my spine. To me it epitomises all that is wrong with enterprise java development.
abhi, I seem to have something in common with you coming from a similar enterprise Java background, and being able to see the shortfalls of this kind of development that CouchDB might be able to address.
Honestly, I haven't used CouchDB in an enterprise environment yet, so I don't know the best way to do things. But one thing that appeals to me is that there is no best way to do things - there is more of a focus of the business needs driving the software decisions in this style of development, rather than the other way around.
Also there is no 'middleware' - nothing that purports to be the software equivalent of a gatekeeper, or something that can prevent or inhibit information flow and also understanding of the system by real people.
There are just a bunch of javascript libraries and tools that you can use to help get your specific job done. There is no need to mandate or architect an ecosystem of frameworks that will keep those poor junior and mid-level developers occupied for the next 10 years.
Just a simple RESTful HTTP database interface, and the application in javascript. If other apps (or a dreaded ESB) need some data, well that's fine - it's there for the taking. If sammy.js will help in your app, then use it. It is just a javascript library - no installation needed - a tool that might help in your specific circumstances.
I know I don't need to convince you - I can see your interest all over the web already... hehe but once I start writing I can't stop.
Useful site. It was very great stuff. Thanks for sharing it.
Post a Comment