Wednesday, October 8, 2008

Too many choices for RIAs...

Notably this, like most of my ramblings, is mainly for thought aggregation and self-reference later, in this case mainly keywords to look up, but if it helps you out then good :).

The number of options for web development is overwhelming! The more complex the application is, the more options you have. For a simple web page its easy -- HTML, and if you want to get fancy you use javascript and CSS. More than that is when it starts to get complicated, you have Javascript libraries like jQuery and Dojo or embedded stuff like Flash, Java Applets, and, now, Silverlight.

Now what if you want to do something on the back-end? There's SSI, PHP, ColdFusion, Python, Java Servlets, JSP, Java Restlets, Ruby... and the list goes on. Hell, if you wanted to you could write the whole thing, web server and all, in C or C++ -- at least it would be fast as hell :).

Now what about databases? MySQL is kind of the open source standard that seems to scale well, but enterprises tend to lean towards PostgreSQL or commercial options like MSSQL and Oracle. I also took a look at FirebirdDB, which looks very interesting. In all honesty I am surprised that more people don't use FirebirdDB and PostgresSQL over MySQL. Then there is also Hadoop... but thats not even SQL.

Then there are database abstraction layers (DALs), and the selection depends on your language. With PHP the most promising ones (for me) are PEAR DB and adoDB (which actually can run some native C code to speed things up, very cool). adoDB works with Python too. In Java there are Spring, Hibernate, and iBatis. I don't even know all the options for the other languages. While there are arguments against database abstraction, some of the solutions make coding much simpler and faster. ORMs in particular look very useful.

Once you start getting more complex interfaces you have to worry about cross browser compatibility which is just nasty. Coding for IE6 as well as standards compliant browsers was awful, just awful. Not to mention debugging and writing maintainable code is non-trivial (thank god for firebug). In short it is a layer that a system architect for a complex RIA just does not want to deal with. There are various options for circumventing this, even some CMSs such as Drupal and Wordpress do this indirectly, but there are a couple packages that do this very elegantly and quickly such as OpenLaszlo, Adobe Flex, and Google Web Toolkit, and one other one I can't think of right off. Here is an interesting article comparing those three.

Next you need to consider reliability, performance, scalability, and code maintenance. In enterprises performance is irrelevant if it is scalable -- you can always just throw more servers at it. This is one reason Java has been so well adopted on an enterprise level; even though it is very slow when compared with C or C++, it is scalable, more flexible, and produces more maintainable code. "Programmer performance is worth far more than system performance ;-)." [1].

For scalability you can look at products like Squid which will do reverse caching and load balancing for web pages as well as sqlrelay which will do connection pooling and load balancing for sql servers. has some cool stuff too.

Since most of these technologies are interchangeable, you can mix and match almost any combination of them; this creates a huge number of deployment options. Hmm, maybe I will do GWT -> PHP -> adoDB -> SQLRelay -> MySQL. Or you could even do PHP -> Python -> PostgresSQL, if you decided you like Python for some of your server interactions and PHP just for templating, and, in this case, you opted not to have a DAL. These are important decisions to make before a project begins, as backtracking can be prohibitively expensive and choosing the wrong architecture can cause problems with stability and development; even worse is its hard to predict how it will scale until the application is completely written. Luckily for small, homebrew, applications almost all of these technologies will be able to handle any load you throw at it, so the common recommendation is do it however you are comfortable with, but when you get in to large enterprise applications then things like persistent database connections, clustering, stability, and collaborative code development need to be carefully considered.

This brings me to a minor point - in my experience it is much easier to write bad PHP code than good PHP code, where as it is much easier to write good Java code than bad Java code. Granted there are exceptions, but the loose typing and script like nature of PHP can very easily lead to unreadable code. Java, on the other hand, is strictly object oriented and tends to lead to better design patterns. Sure a bad coder can screw up either royally, but it is something to consider while choosing a collaborative language.

So far, after looking at all of these packages, GWT -> JBoss -> iBatis -> WhateverSQL [2] looks very, very, promising for quickly producing scalable and maintainable RIAs. GWT makes communication between a browser and a Java Servlet seamless and lets you stay away from the HTML/Javascript pit of death. JBoss has all sorts of neato scalability. iBatis looks like a great ORM that doesn't abstract the SQL too much; it also does connection pooling and balancing. Lets assume WhateverSQL has seamless clustering and replication ;). This looks much easier (and cleaner!) than HTML -> JavaScript -> PHP -> adoDB -> SQLRelay -> WhateverSQL. We'll see how it goes. Here is a nice little tutorial for GWT + iBatis.

[1] rycamor
[2] I actually just don't want to put that I am using Oracle for this particular project... Who the hell pays $40,000+ for one license when there are so many free options? It may have some cool features, which I have yet to see, but unless it writes the damn webapp for you then just use Postgres.

Alphabet Soup:

PHP -> PHP: HypeText Preprocessor
RIA -> Rich Internet Application
SQL -> Structured Query Language
HTML -> HyperText Markup Language
GWT -> Google Web Toolkit
MSSQL-> Microsoft SQL
CSS -> Cascading Style Sheet
adoDB-> Active Data Objects DataBase
ORM -> Object Relational Mapping
SSI -> Server Side Includes
JSP -> Java Server Pages

No comments: