Daniel Alexiuc Enterprise Web Application Architecture 2.0 and Kittens
According to its homepage, CouchDB is a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API. 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:
- Login or register to post comments
- 5829 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Ronald Miura replied on Fri, 2010/02/05 - 5:54am
Joel Samildanach replied on Fri, 2010/02/05 - 8:38am
Tracy Nelson replied on Fri, 2010/02/05 - 12:34pm
Clue: in most "enterprise" situations, you aren't the only one using the data. You try telling the guys in Billing or Purchasing that they'll have to parse JSON strings or DOMscrape your web app (because you moved some business logic into the UI) and you'll find yourself embarrassed in a meeting when you find out that nobody's using your app because it's more effort than it's worth to integrate with it. Your data access layer's there because in an enterprise, you'll likely need data from more than one source. Your application layer's there because you'll probably need extended validation (like: will we have to split this customer's order to bill it across two or more purchasing contracts?) or to coordinate with other systems (is there enough product in stock to satisfy this order? If not, will a shipment come in before this order has to ship?). Your presentation layer is there to do the grunt work so you can show a customer a summary total without having to ship a couple hundred lines of data to the browser and computing the total client-side. Like jsmildanach pointed out, the whole lets-put-all-the-business-logic-in-the-database movement died out years ago, and for good reason.
At least you got the kittens right...
John DeHope replied on Sun, 2010/02/07 - 11:48am