Rethinking Web Application Development Choices

Oh man…its has been more than a month that I blogged I am posting this half baked blog just to keep my blog rolling. I am still working on this post, trying to create a comparative table, but till then below are some thoughts on web application development choices.

A dynamic web application, minimally, involves 1) a database, 2) a server side scripting language, and 3) a front end. At each level, developers have many choices to choose the right combination of technology for their web application. While, it is good to have choices, one also has to carefull in picking the right technology depending on his own level of competency and project requirements. Based on my own experience, I have jotted down some choices and concerns one should be aware of when developing a web application:

MySQL, Postgres, Oracle, DB2, Objectivity, MSSQL, etc.

When picking a database for any project, I always think about these concerns:

  1.  RDBMS vs. ODBMS vs. ORDBMS –Relational Database Management Systems (RDBMS) are one of the most widely used database management systems (DBMS). For most applications, they provide robust solution. However, certain applications such as those concerned with hierarchy, RDF/OWL, object oriented can be more efficiently modeled using Object oriented databases (ODBMS) or object-relational database management systems (ORDBMS).
  2. Open Source vs. Free vs. Proprietary
  3. XML Support –Some database such as MSSQL provide an inbuilt XML datatype. Thus, you can store, retrieve and query XML as any regular (int, text) datatype.  Although, I don’t like MSQL at all, I found this ability to be very useful in many applications. Mainly, as the web applications are moving towards Service-Oriented-Architecture (SOA), the ability of a database to natively handle XML gets increasingly useful.
  4. GeoSpatial Support –Increasingly geospatial applications are becoming common. Google Mashup, Virtual earth, etc are just tip of the iceburg. Oracle has a long history of providing good support for geospatial applications. It supports basic topological operators such as overlap, intersection, etc. In open source community, increasingly, Postgres is becoming the default choice where-ever an application needs GeoSpatial support.
  5. Full-Text Search –
  6. Efficiency –
  7. Deployment –
  8. Community support

Server Side Scripting Languages:
PHP, Ruby, Java Servlets, Python, Perl, etc

  1. Community Support
  2. Efficiency
  3. Object Oriented
  4. Scalibility

Front End:
On the front end side, the choices can be mainly divided in two types. First, the traditional technology of using HTML along with Javascript, CSS, and Ajax. Second, using rich internet application technology provided by Adobe (Flex) and Microsoft (Silverlight).


  1. Search engine optimization – While traditional webpages can be easily scanned and searched by robots, this is not true for rich internet applications.
  2. Application loading time  –if application loading time is critical for you, then using traditional HTML approach is a better idea. Flex and Silverlight requires loading libraries and there introduce significant latency when initially loading the application.
  3. Rich interactive visualizations –If your application requires providing rich web based visualization such as interactive maps, graphs, network charts, etc., using RIA’s provided you with much more options.




3 thoughts on “Rethinking Web Application Development Choices

  1. For your information: Adobe Flex 3 has a number of features that allow you to minimize the loading time of your Flex based RIA application:
    – the Flex runtime library doesn’t need to be compiled into the application and can be shared with other websites.
    – an application can be split into runtime loadable modules. The initial load time can be minimized this way.

    The ‘bad’ thing about RIA’s is that they’re not really SEO friendly. Especially when building an e-commerce solution this needs to be kept in memory.

  2. Why would you want to store XML inside a database? wouldn’t it make more sense to store objects or attributes inside your database or program and only convert to XML when you need to communicate with an external client?

  3. @Tom – you are right about SEO friendly issue. However, I am not sure that RIA will ever beat traditional webpages in initial loading time. According to many statistics, users spend less than 3 seconds when randomly browsing website and any loading time will only discourage user from using that website.

    @Ian – Consider a situation where you database is mainly a repository for different visualization to dump their state at different time instant. Since you are not sure what kind of parameters each view requires, you can easily use a column with XML type where views can store random parameters.

    The good thing with XML data type is that now you can use XPATH query to filter records that satisfy any particular parameter. For instance consider a geographic map view. Suppose we save the state of a map at time t and store following parameters in the XML column – center point of the map, its width and height, and zoom level. Now, you can use XPATH query to search for maps that have any particular center point at a specified zoom level.

    I hope this convience you that XML data type can be useful in some instances, mainly, when you are dealing with many different clients and they vary in suttle ways on what parameters they need to store

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s