GORM Recipes

As I’ve been diving into Grails, one of the most frustrating parts I’ve had to deal with has been GORM. It is deceptively easy to do the simple stuff with GORM. But as soon as I got to the point of wanting to do aggregate functions, grouping, or other more sophisticated queries, I ran in to wall.

Rather than diving in to SQL, I opted work through the documentation and various blog posts to find the “GORM Way” of doing things. I also documented what I found. The result is this rather extensive article on GitHub called GORM Recipes.

The text was way too large for this blog, so I opted to put it on GitHub. This thread is for feedback and questions about the GitHub article.

He Chose Poorly…

Some of you may remember the title of this post as the famous last words in the epic Indiana Jones and the Last Crusade. The wise, aged Crusader dead-panned this line right after the evil villain crumbled to dust after drinking from the wrong grail. This post is about Grails, and that scene came to mind when I was writing it.

Turn back the clock four weeks. The president of our company decided we needed to add a new sales channel to our system, and we had to do it quickly to stay competitive. The deadline was set before we even saw the requirements and we just needed to “back in to it.” Ignore for a minute how insane this sounds. My larger concern was the impact to our system. My predecessors designed the entire application around two sales channels. Worse, it was handled via an infinite number of ‘if’ statements along the lines of if not (channel A) assume (channel B). We had just been asked to add Channel C.

Based on the compressed timelime, it would have taken us the entire schedule just to go through the code and unwind the “A or B” logic, nevermind actually adding the new functionality. So based on the narrow set of requirements, we decided to build a whole new application on the side. It was to be an 8-10 page website with a big form, web service calls, database access and some AJAX. Our currently application is a Java/Struts/Hibernate webapp deployed to Tomcat, so I wanted to stay in that comfort zone, but I saw this as a chance to test out something new.

The obvious choice for us was to try Grails. The five developers working on the project were all senior, with 5+ years of experience pounding Java code. We toyed with using Rails, but I didn’t want to introduce too dramatic a technology shift. We figured the project was going to take the team of five about three weeks to get to a testable state. Allowing for some ramp-up, that worked out to around 500 hours of effort for the team.

The team was excited about Grails from the get-go. Most of us had run through the basic tutorials, and were enticed by the prospect of increased productivity. We’re coming up on the end of our development this week, so I discussed our choice to use Grails with the whole team, and factored in my own impressions.

The general consensus of the team, now that they had used Grails in the real world, is that it really wasn’t worth it. Most would use it again, but the real-world productivity increase was more an illusion. The boost Grails gives is setting a clean project structure. Once it comes time to pound real code, that head start evaporates quickly.

One of the biggest gripes is poor tooling support. My team used a combination of Eclipse and STS. To a person, they all said the tools were very weak in helping them out when things went sideways in Grails. We ended up spending extra time trying to debug issues that would have been caught quicker in straight Java.

The dynamic nature of Grails is both a blessing and a curse. It can tighten up the code, but can lead to some difficult-to-troubleshoot errors. My favorite error was when someone used contraints {} instead of constraint {} in a domain class. That stopped us dead for half a day until someone finally noticed the error which the compiler was more than happy to digest.

The one part of Grails everyone appreciated was the web tier with GSPs. That piece works extremely well and really does make life easier. But one of my guys commented that we could pretty much get the same thing using FreeMarker with Spring MVC.

From a management perspective, I was disappointed with how quickly the productivity with Grails plateaus. I’m satisfied we completed the project on time, but I can’t credit it to Grails so much as our drive to limit scope and maintain focus. I believe we could have also reached the finish line using a straight Java/Spring/JPA stack and it would have been easier to work with.

For me, Grails fits in to the “conceptually cool” bucket. For “lone genius” coding, it can probably be very productive. But if I were doing the lone genius thing, I would just use Rails instead of Grails. The spot Grails is trying to fill is the “I want Rails but can’t” space. It is a way of introducing almost-Rails into an enterprise already using Java. Unfortunately, in a team development situation, I didn’t see almost-Rails buy us anything.

The one unintended side-effect of this project was that it piqued my interest in Spring Roo. I wasn’t convinced it was useful, but I’m thinking I could see the same quick start of Grails while keeping the project closer to the known quantity of Java. I’m going to have the team attempt to port this project to Roo when things calm down just to get a more educated impression of it.

If Grails floats your boat, more power to you. A lot of work has gone in to it by a lot of very smart people, and I won’t knock that. Dedication like that keeps the programming field interesting. But in the same way I don’t see a use for JRuby, I don’t see me using Grails again. If you’re good with Java, I would recommend continuing to master your tool over chasing the holy grail. We know how that can end up.