Which server technology/framework should you choose to build your next minimum viable product?

When I started out to build MediaNearby, I spent almost 8-10 weeks evaluating the best-fit technology to build a minimum viable solution. My learning? When you start out, have just one criteria - whatever lets you build the core functionality with minimum amount of time. Evaluating for scalability, flexibility, etc is a waste of time. I am documenting my experience so developers with similar background and problem set find this helpful. I am assuming that the front-end technology used would be HTML5 and Javascript.

I have spent close to 7 years developing java based applications. Hence I am naturally comfortable with this programming language. My requirement was to develop scalable search and cataloging and I did not want to build something from scratch if robust libraries were already available. I wanted to deploy the system on a cloud service provider like Amazon EC2 or Google.

The problem with being a “techie” is when you evaluate a technology you want to dabble around with cool new technologies for as long as possible. Learning a new language is as exciting as buying the next cool gadget. Without a clear objective/criteria one ends up wasting time instead of making progress.

I started evaluating technologies to build the server side logic around early 2010 . The most popular web 2.0 frameworks were Ruby on Rails and Lift-Scala (Twitter had rewritten their servers in Scala, FourSquare is on Lift-Scala). Node.js was just becoming popular. I briefly looked into Grails as well.

I spent some time to learn Ruby and Rails trying to understand new constructs like closures, convention over configuration, scaffolding, and so on. One of the challenges with Rails was that the concepts around packaging were very different compared to Java and I could never get my head around how “gem install” worked. The other issue with Rails at that time was that it was not easily portable across cloud platforms. Google appengine did not support Ruby and one had to use a JVM (jRuby) to run Rails. jRuby was always a step behind Ruby versions and that did not help. Rails also required one to build C based modules for frameworks like jRuby for which the base modules were not available.

It soon became apparent that java was a popular ecosystem supported by cloud environments and running a framework based on Java would make life easy. The popular JVM based script languages were Scala and Groovy because of availability of Lift and Grails frameworks respectively. Lift and Scala was being used by Twitter and provided a high-performance ecosystem. So I decided to try out Scala next. Scala as a programming language is easy to understand once you learn Ruby as it has similar constructs. The big challenge was understanding Lift. For someone who has an MVC background, understanding the “build view first” and then the rest architecture was extremely difficult to understand. Also, the documentation for Lift mostly focussed on ‘Chat’ kind of applications that fit well into the Comet based architecture. Though I gained understanding of how Lift works later, at that time it was a no-go.

The next natural selection was Groovy and Grails. When I dug deeper into Groovy I was surprised to find how well it integrates with the Java language and also makes use of enterprise grade technologies like Spring and Hibernate under the hood. The big bonus was the ability to use any opensource or commercial libraries that have been developed over the last 15 years. Also the plugin based architecture of Grails made the framework quite extensible and was helping to build an active ecosystem around this framework. SpringSource endorsement of the framework and active participation was another plus.

The Groovy language constructs are similar to Ruby or Scala, but Groovy also allows one to write java code. Calling a java library and vice-versa is a first-class language feature in Groovy. Features like convention over configuration, scaffolding, templates, partials, tag-libraries, plugins and an MVC architecture at the heart of the framework resonates very well with Java and Spring developers. Deploying a grails application is simply copying a war file to a web servlet container.

I also realized that ramping up a java developer in Grails would be easier than other frameworks.

The combination of familiarity with java, convention over configuration, availability of a comprehensive set of libraries, ultimately helped the decision to choose Grails.  For someone with a background in Java and java based open-source technologies, trying to build a minimum-viable-product, I would strongly recommend Grails/Groovy over frameworks like Rails, Django, Lift, Node.js, etc

Adaptive Javascript in Grails with JQuery

The Grails framework uses a technology called Adaptive Javascript that enables easy development of Ajax requests. Developers can code Ajax enabled links and forms using a set of standard grails tags such as <g:remoteLink> or <g:remoteForm> in Groovy server pages and Grails internally generates the required javascript code to send the Ajax requests to servers based on the javascript library configured to work with Grails. Grails uses the Prototype library by default and the 1.4 version promises to move to jQuery as the standard. The code written is non-obtrusive, i.e. if Javascript is not enabled the forms or links will work as normal html forms or links respectively.

There is one caveat to using this method though. There are cases where the developer is required to call a custom function based on the result of an Ajax request. The standard documentation states the method signature to be used for such Ajax events of the form “onSucess=’fireMe(e)’”

This is typical to the Prototype library and does not work with jQuery. When using jQuery, the browser will complain about unknown event ‘e’. The way to get this working is to make sure the signature used follows the accepted jQuery standard which is “onSucess=’fireMe(data, textStatus)’” where data is the response data of the Ajax call and textStatus is the HTTP status of the Ajax request in string form

Update Nov 2011: As of Grails 2.0, the default javascript library is JQuery and the Prototype way of adaptive javascript no longer works. Please refer the Grails framework documentation.