In the recently concluded annual technology conference of my organization, the keynote speaker Kirby Ferguson presented his talk “Everything is a Remix“. It also appears in TED. Watch it, its pretty good. Sometime last year, I had posted a blog on the similar theme, that we do not really invent anything. All we do is look into recycle bin and pull out existing ideas, but “innovate” just enough to present in a different form.
I remember one of my first implementation of a functionality in Visual Basic, back in 1995 – drag-n-drop a combobox from Toolbar panel, open the properties page and set the database connectivity properties, select a few columns, click on some validation checks and voila, the client retrieved the data from db! How simple can it be? Apparently not enough.
In writing web applications, there are two main styles – component based frameworks (CBF) and action based frameworks (ABF/MVC). Both have pros and cons based on the needs and perspectives and the war between the two seems to shift in balance of victory from time to time. Microsoft started with a CBF Asp.net solution and eventually dumped it to go towards MVC. Java started predominantly with ABF and later geared towards a few CBFs (JSF, Tapestry, Wicket etc).
In the ABFs, the individual layers are abstracted on its own – abstraction of views by GSP, jQuery, Angular, Express, Ember etc; abstraction of server-side by Grails, Rails, Spring MVC, Asp.Net MVC etc. and abstraction of data access by GORM, JPA, Hibernate, Spring Batch, Spring Data etc. In case any of these frameworks go out of fad, it is only necessary to refactor that abstraction and its relations, instead of rewriting the whole solution.
The challenge with the web technologies now is that newer simpler ways of achieving the same results are happening too fast. Granted, the protocol (http) itself is not changing, at least for now (WebSockets anyone?), but what changes is how data is being mined, how it is being groomed and how it is being presented. Let us take a short look at the three layers – mining, grooming and presenting.
Data-mining: The advantage with document dbs is you get to store your model as you want to be, not as what the datastore dictates you to be. If you evaporate all the data objects, it will basically residue down to two: Map and List. Neither is “natively” supported in an rdbms. You have to decompose them to some id and, more importantly a relation.
Data-grooming: Many data-grooming happen around xml and json. Unfortunately for xml, from being a mere human readable representation by strings, it took a very impractical turn – complicated schemas, explosion of verbosity, confusing binding libraries, generic representation of data types, configuration and code logic. It falls by its own weight of abstractions. In a traditional web application, think about the data conversions that you do – they take about 60% of the effort – converting from request input to command objects to domain or service layer objects to stored procedure models to actual data! And all the way back to presentation layer! (N+1)-Tier FWIW!
.where(“Customer.CompanyName”, “startsWith”, “Alfreds”)
So querying the database domain models directly from presentation layer? Heard of it somewhere? Yeah, I heard that first in Visual Basic. Everything is a remix indeed!