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.
- 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