Grails: First Project

Groovy and Grails has been much talked about in the last couple of years and though I’ve fooled around with small sample projects I never really had the chance to do anything more. Recently, a client approved to use Grails on a new J2EE web application and this will be my first time using it on a large complex system.

There are many postings that talk about the general positives of the framework, but in this article, I want to focus on what worked and didn’t in my project and in particular, what didn’t work. My hope is after you read this article, my insights on using Grails for the first time will help you make the right technological decisions for your project.

Introduction

I am no Grails expert.

The team started up with Grails very quickly. As new members joined the team, the overall ramp up time was, as advertised by Grails, very quick and pain free. As you all many know, ramp up and installation of traditional J2EE applications can be extremely painful and take a lot of time, so the ease of ramping up new members was a great relief.

The transition between traditional J2EE to Grails was easy. I would attribute this to the “Convention over Configuration” paradigm that Grails (and Rails) use. By understanding the convention and looking at samples and existing code, developers were able to focus on implementing business logic rather then figuring out how XML configurations and flows work.

Positives

  • Easily change the domain model without having complex SQL migration scripts.
    With a domain model actively changing thoughout early development,
    incorporating the changes in short time would not have been possible.
  • Most of the advantages as advertised by Grails worked for us.
    Such as: clear built-in separation of environments, GROM, automatic binding, etc
    See the additional resources for a other postings on the advantages of Grails.
  • Active Groovy and Grails community. Even for a new framework, there is substantial
    knowledge on the internet and questions are quickly answered by the community.
  • The small things: Groovy syntax, smoother development, integrated environment.
    All that dynamic synamic syntax and sugar code.

Negatives

  • The installation of the plugin in directories outside the project and
    overall in-house plugin setup via the IDE added much confusion during the
    periods of active development of those plugins.
  • Though Springsource’s STS Eclipse integration with Grails is pretty adequate,
    there are some annoying gotcha’s that keep creeping up, especially dealing with
    the installation of in-house plugins.
  • Some developers can to revert back to standard Java techniques when exposed to
    difficult situations. For this reason, I found code reviews very important.
    Detected in reviews, the more experienced reviewer can often pass knowledge on
    how to solve a particular problem the Grails way.
  • Though novice developers can quickly become significant contributors, without
    a solid knowledge in Spring or Hibernate, it is often left up to the more senior
    members to deal with strange Hibernate errors.
  • We are developing the application using the built-in Grails development
    (Tomcat and Java DB) environment. However, the test and production
    environments are using a WebSphere server and Oracle database. Though development
    though Grails is faster, we have seen a number of gotcha’s
    during our switch over to the WebSphere and Oracle database.
  • These compatibility issues do not produce meaningful Exceptions messages and
    usually require a trial-and-error approach to figure out the problem. Examples
    are restricted Oracle keywords used as properties on domain objects and issues when
    Controllers and Domains share the same name as certain WebSphere classes.
  • It remains to be seen how well the client’s IT teams will adapt to
    this new technology.

In conclusion, I would recommend Grails as a framework going forward. Much of Grails’s advertised benefits are true and work. The big question remains is how organizations who are used to traditional J2EE frameworks such as Struts and Spring can adapt to using dynamic language frameworks such as Groovy.

As development continues, I will update this blog entry.

Additional Resources

Here are some additional resources to help you decide if Grails is right for you.

Leave a Reply

Your email address will not be published. Required fields are marked *