Don't Choose Your Middleware Language or Architecture: they are consequences
I'm writing web applications and need to decide on every piece of technology involved. What are a logical set of choices?
On the server-side, I want the data stored in a proven reliable system. There are many technologies on the rise (e.g. CouchDB) but right now it seems that a relational database management system (RDMS) like PostgreSQL is the solid choice. Data storage is not where I want to be on the cutting edge.
So what do the above choices this mean for my server-side middleware language and architecture?
DRY is about more than just sharing source code. Needing to switch between two languages all day long means repeating the process of becoming an expert in two languages. Knowing multiple languages is a very good thing and I've studied several at least at an introductory level; however, becoming a true expert in a language takes years. One day I might be an expert in just one language. It makes sense to me to get the most return on my invested time and learn one language well and program production code better on both the client and server sides rather then splitting my time between two languages and writing mediocre code everywhere.
Persisting data in the database is a fundamental activity of a web application. The object-relational impedance mismatch is well known and a result of choosing an RDMS for its strengths but still wanting an object-oriented programming paradigm. An object-relational model (ORM) is used to bridge this gap. Since the gap is reasonably wide, the ORM is a substantial piece of software. This is another big piece of software that needs to be written before business logic can be expressed. There are many ORMs available but whenever the object model doesn't quite match a normalized database schema for some complex data the whole deal seems to fall apart and it is a great struggle to wrestle the ORM into submission.
There are many examples of data sets which we manipulate daily without an ORM. For example, the UNIX operating system provides all sorts of tools for you to create, read, edit, move and delete the files on your hard disk. When you are at the terminal command line and use
ls -l you receive rows of data you then loop over or pipe to grep. This is not object-oriented and it works well. In our server-side programming of a web application, why don't we just build tools (i.e. functions) which abstract database access and operate on sets?
So I won't be using an ORM. I'll embrace the idea of sets.
My choices of client-side and data storage technologies have driven the resulting middleware language and architecture. It is more common that developers do it the other way around. For example, they first decided to program the server-side in Java or Ruby with a very object-oriented style because they like that language and style of programming. Then to indulge this whim they must develop thick adapter layers on either side of this middleware to interface with the database and client. Witness Hibernate and GWT in Java or ActiveRecord, RJS and HotRuby in Ruby. Something is wrong with the order of decisions being made if they results in a need for such large adapters layers to apparently "make things easier." It seems to me better to go with the flow of constraints outside the middleware layer will result in a much thinner middle layer.
Have something to write? Comment on this article.