Friday, September 4, 2009

Grails

There was an interesting article (I think on slashdot but couldn't find it) the other day about a statistical analysis of forum questions regarding .NET, EJB, Grails and Ruby on Rails. It basically said that the number of questions on .NET and EJB was higher on the weekdays; Grails and Ruby on Rails questions went up on the weekends. This leads the author to the conclusion that programmers, in general, feel that .NET and EJB are not as fun as Ruby on Rails and Grails.

After reading the above article and writing what felt like my 18th abstraction class in AppFuse to allow me to change from Hibernate if I ever wanted to, which allows me to change my database if I ever want to I decided to try Grails. The very first thing a newcomer like myself finds is a paradigm I was not really familiar with: "coding by convention". What this really means is that all those naming conventions that are not important, except if you don't follow them you have such a mess of an app that no one could ever figure out how to make any changes, are used by Grails instead of XML configuration files. What this means concretely, taking struts as an example, you have an MyAppAction that has a MyAppForm and is reached from a URL http://localhost/myApp. To make that work you have an XML file, which has (wait for it) duplicate information. Grails takes the names and figures out much the same way a human programmer would that these are all related and doesn't need any XML to glue it all together. Why do programmers allow this struts example anyways? We hate this type of duplication, and yet there it is. I am not picking on struts either, I like struts, most frameworks are like this.

Another nifty part of Grails is some really cool database abstraction technology. The GORM persistence technology is really powerful. It actually reminds me of something called Relational Views that ATG had in their Dynamo product about 10 years ago, but taken to the next logical level. The GORM tutorial provides for a nice casual read that shows what it can do conceptually much better than I could.

The ability to auto-generate HTML for listing, and editing database entities is just great. If you are creating a simple CRUD application or a prototype you can be off and running extremely quickly. For example the reason for my app (the web portion anyways) was a simple web app that had a couple of database tables and required a user to log in. I carved out the web part into 2 different phases, phase 1 is a single table to be viewed and updated, basic authentication that would be kept in the database with a single user type. Phase 2 has some more associations where certain users can only see data that they are authorized for, and an admin module for the user. With Grails I built phase 1 in 4 hours...and I am sure someone more familiar with Grails could have done it in about a quarter of that time.

I was going to write about my experience with it, but there is not a lot to write about. Here are the 2 tutorials I used, they were great.
  • Official Quick Start
  • Logon Tutorial. There were a couple problems with this one if you go here and search for "Simple Login Tutorial" you will see the corrections. Still very simple to read and follow.
When I move on to phase 2 I hope to get into some more interesting bits of Grails and Groovy and post something here.

With all this said I don't have any real experience with how Groovy performs, or how maintainable Groovy would be with a group of people. I suspect a Groovy app would be fine in a production environment as it is using Spring and Hibernate after all is said and done. As for maintainability the framework itself enforces (or heavily encourages anyways) proper naming conventions which would be a big plus, but the use of groovy is not as well supported in most IDEs I think.

3 comments: