Cantina Consulting

First let me congratulate all the folks that have been going crazy getting the Groovy on Grails (grails.org) framework to version 1.0 (almost there!). Just when I think my 0.5.6 version is going to be around for a while, they start releasing more versions, with a fury.

We’ve used Java here at Cantina on innumerable projects with a great deal of success. The toolset is very complete and Spring and Hibernate have been a godsend for allowing us to focus on the intellectual "meat" of a project. Then, in an effort to explore some new technology for a couple prototypes we were working on we found Grails.

I think the first thing that drew us (me) to Grails was the mantra that I heard over and over again at a talk given by Venkat Subramaniam at Sun a while ago regarding Groovy on Grails have more "signal to noise". Less syntactical noise, more code signal (i.e., the "meat"). In his talk he threw together an AJAX enabled form in about 10-15 minutes with all the CRUD and validation you need.

Once we started using Grails in house, it quickly became apparent how deep the mantra of having a greater "signal to noise" went. We love Spring and Hibernate but we hate XML configuration. Yes, XML is ubiquitous, very readable, and supported everywhere, but, as technologies like Spring and Hibernate put more of our application structure into XML, it makes it very hard to debug all of our application when some of the structure sits in very static XML.

Grails provides a great approach to this. Through the Grails BeanBuilder, you specify all of that lovely Spring configuration within a very readable and debuggable Groovy syntax. This makes for a much more powerful way to configure the structure of your application as well as allows you to actually step through parts of your configuration with a debugger.

Of course, Grails does a whole lot more than that (including a lot of the auto-wiring in Spring so that you don’t have to do any configuration), and here are just some of the things that caught our eye:

• GORM (Grails Object Relational Mapper): as if Hibernate wasn’t powerful enough, Grails adds some useful methods of querying and mapping your object model that go above and beyond Hibernate. With dynamic methods, you can query against properties of your object model classes (domain classes) via methods that you never have to write, like this:
  
  // Assuming you have a domain class called "Person"
  // with a name property and a type property that
  // can be "employee" or "customer"  

  def allPeople = Person.findAll() 
  def onlyEmployees = Person.findByType("employee") 
  def howManyEmployees = Person.countByType("employee")

  I didn’t have to write any of these find* or count* methods, they come free of charge with GORM which makes the simple queries a lot easier to manage.

• Auto-reloading: one thing that has always plagued us as Java developers is the development cycle of fix -> deploy -> start -> test. There are certainly ways to reduce this cycle in Java, but sometimes the project just doesn’t allow for it. Grails is built with the mindset that changes to most code assets should be reflected instantly in the running application, thus reducing the time it takes to test code changes
• TagLibs: Creating GSP (analogous to JSP) tag libraries requires much less code and no configuration to get your tags and and running
• Intellij IDEA Integration: I love TextMate as much as the next guy, but code completion and debugging are things I’ve just gotten too used to (call me lazy). The Groovy/Grails plugin for Intellij IDEA has come a long way towards making Grails a first class IDE citizen.
• Legacy Integration: A lot of the projects we work on involves an existing Java application and SQL database. There is often business logic already implemented in Java classes (Spring or otherwise) that really don’t need to be rewritten. Since, at the end of the day, Grails is Java, we can make use of the existing codebase in a way that is much more seamless than if we were to introduce another web technology. Also, the fact that it’s all Hibernate under the hood makes it easier to adapt a set of domain classes to an existing database schema. This makes Grails an easier sell on those technical re-architecture projects in the Java world.

Beyond the technology, there’s just a lot of momentum in the Grails community. Within the last year that I’ve been watching, Grails has gone from a 0.4 to just about 1.0 (I’ve been using PHP frameworks that haven’t bumped the minor version number in over 2 years). There’s a healthy and growing list of plugins (grails.org/Plugins) that seem to be addressing the core needs of new application development.  We’re really looking forward to the next Grails project and experiencing a lot more signal and a lot less noise.