My experiences with Grails

For a private project, I have been using Grails for a couple of months now, and altogether it was a very pleasant experience. In this post I would like to highlight some aspects of it.

For me, being a Java developer, getting started with Grails was really easy. Here’s why:

  • Grails builds upon usual suspects: Spring and Hibernate, each of which I have years of experience with
  • The conventions used in its convention-over-configuration mechanism made complete sense to me
  • Documentation is pretty good
  • It has a lively and supportive user mailinglist
  • You gotta love Groovy.
  • GSP (the grails counterpart of JSP) just does everything right
  • Spock is a great unit testing framework

I was developing in Grails with IntelliJ IDEA version 10, which has excellent support for Grails. Setting up a project is trivial.

A couple of things to be aware of / that I’ve learned:

  • Grails pre-determines the Spring version that is in your project, and understandably so. With Grails 1.3.x it gets Spring artifacts from SpringSource’s EBR. This means that you have to be careful when including other artifacts that may refer to the regular maven-central style artifact names. Apparently this will change come Grails 1.4. You can deal with this problem by running ‘grails dependency-report’ and excluding artifacts in BuildConfig.groovy
  • Grails controllers are request-scoped, unlike your familiar Spring MVC controllers
  • There are a lot of plugins available for Grails, but they vary wildly in terms of quality. Do read the source.
  • Grails comes with the Prototype Javascript library, but it is really easy to switch to jQuery. Apparently,  jQuery will be the default as of Grails 1.4
  • If your application sends mail, the greenmail plugin is pretty nice. No more waiting for emails to arrive at development time.
  • When adding plugins, be aware of which controllers / services / meta-methods it adds. Sometimes you don’t want them to be exposed.
  • Pure unit tests run a bit slower than I would like, but on my 2009 Macbook Pro I can run a Spock unit test with about 10 test-cases within IntelliJ in about 5 seconds. That’s acceptable.
  • The Spring Security plugin is great, but pick your means of securing resources carefully, as they are mutually exclusive.
  • The Hudson/Jenkins Grails plugin is nice and does the job. It would be nice though if it didn’t mark a build that has one failing test as ‘failed’ but as ‘unstable’. But I believe this is caused by the grails command exiting with an error value when a test fails.
  • Only in rare cases do you have to restart your local app while developing, so turn-around time is very small.
  • Doing basic AJAX is really simple with Grails. Its GSP taglibs and JSON support help out a lot. Combined with the jQuery plugin life is easy.
  • Modularize your app by turning parts of it into plugins. It really is quite easy.
  • A great find was the fixtures-plugin and its accompanying build-test-data plugin. Writing integration tests for complex queries was never easier.

All in all, Grails allowed me to get productive very quickly. I did not spend time on setting up web.xml, configuring spring, configuring data sources etc etc. Instead, I could focus on the task at hand.

Given the fact that the Grails always offers you a way out if you need to do very specific stuff in Java, I think Grails is probably going to be my default weapon-of-choice in the time to come. People that think it isn’t enterprisy enough because it’s powered by a scripting language are misguided. Sure I had my annoyances with it, and maybe I’ll blog about those later on :)


8 Responses to My experiences with Grails

  1. Kim A. Betti March 16, 2011 at 6:21 pm #

    > Do read the source

    This is _really_ important! I do hope that people will continue to make the plugin source code available when Grails 1.4 arrives with support for binary plugins.

    Nice post by the way! :-)

  2. Hans Westerbeek March 16, 2011 at 8:42 pm #

    Well I suppose that in some cases it may be more practical to pull in a plugin as a JAR, just like in Java projects. But for almost all of those jars in java projects I have always been able to get a source distro.

    Not making the source available would be very much against the spirit of the Grails ecosystem. It is plugins that are on github that have a chance of success.

  3. Matthias Hryniszak March 16, 2011 at 9:55 pm #

    You made some excellent points here. The one thing I like the most is the “enterprisy” thingy you mentioned. I mean, when will people finally understand that in fact all the applications, even the biggest ones, can be composed out of small, easy to maintain and create blocks?

    In OOP we’ve already figured out that composition is a better approach to many problems where inheritance is simply a failure in understanding of the basic principles of object-oriented programming and design. So do enterprise architects still live in the early 90’s?

  4. Dan W March 17, 2011 at 6:25 am #

    I think you nailed the spirit of grails dead-on. Like.


  1. An Army of Solipsists » Blog Archive » This Week in Grails (2011-11) - March 20, 2011

    […] My experiences with Grails […]

  2. GroovyMag - the magazine for Groovy and Grails developers about Groovy programming and Grails development - March 22, 2011

    […] Westerbeek tells of some things he’s learned from his experience with Grails. (He summarizes thus: “I loved […]

  3. Musings of an independent start-up developer: a postmortem | Enhance ICT :: Web-based Java Applications - March 25, 2011

    […] A couple of months passed, and I would spend at least 10 hours a day working on the site and things were looking good, not in the least thanks to Grails, which I recently blogged about too. […]

  4. Grails cette semaine (2011-11) – Traduction de l’article original - April 25, 2011

    […] Mon expérience avec Grails […]

Leave a Reply