Monday, August 17, 2009

The Case for Grails

David Jacobs, a friend and colleague, posted a comment in response to other comments on a previous post. The comments focused on scaffolding in Grails.

I thought it was worthy of a full-blown post, and he has kindly granted me permission. David's thesis is that there is much more to Grails than just scaffolding and quick demos.

By David Jacobs:

I've now been using Grails on my primary project for about 16 months (not just toying with it--this is at my "real job" on a large project for one of the 50 largest companies in America). My appreciation of it has continued to grow, and I have complete confidence in it as an appropriate choice for 95%+ of business applications.

Scaffolding is NOT a primary benefit of Grails. It enables cool 5 minute demos, but the real world benefits of Grails are much deeper. There are simplified (auto-wired) conventions, built in tools, or plugins for nearly every aspect of web development. This enables a massive increase in productivity by enabling and encouraging clean solutions that don't re-invent the wheel. Perhaps even more importantly, this keeps the code lean, which is very important for long-term maintenance, refactoring, and preventing "sleeper defects" that tend to hide in bloated code.

I needed to add caching for some web service calls to improve performance: 11 lines of code (entirely declarative).

To meet a versioning requirement (lock, copy as new revision), I needed to implement deep cloning of a persistent domain tree with child associations (mostly collections) five levels deep, with multiple branches, touching about 30 persistent objects. Some needed to be copied by reference (for example, a createdByUser association), and some cloned as new (recursively deep cloned). My implementation is completely generic and won't require changes if the domain model is changed. Pass the method a domain object instance, it hands you back a copy with all of the children copied and properly attached to their new parents. Then you call .save(), and all of the new ids are generated and your database has been updated. This one is a testament to the power of Grails metaprogramming with GORM and Groovy: 22 lines of code.

I needed to create a utility application for mocking a third-party SSO module to enable logins on staging/demo servers. It validates user inputs, makes an AJAX request to the target app with modified request headers to initiate a browser session, and launches it with the intended user now logged in. It uses a proper MVC architecture, the layout is configured with SiteMesh, it has configuration/build management and versioning, URL mapping/redirection to keep it friendly, and log4j integrated and configured. From creating the project to building the WAR file, it took 4 hours.

Point proven?

4 comments:

mavenraven said...

The Case against Grails:

Maven.

My knowledge may be dated, but the layout of Grails project is not compatible with Maven webapps and this makes creating a maven enabled grails project play happily with other maven projects a pain.

David Jacobs said...

@mavenraven

As of Grails 1.1, Maven 2 is fully supported.

http://www.grails.org/Maven+Integration

Luke Daley said...

“fully” supported is a BIG stretch.

As it stands now, it is a bit painful to use Maven with Grails. It's not impossible, just a bit painful.

Anonymous said...

If lack of maven is a show stopper please by all means don't jump in.

You must enjoy xml and annotations hell.

The Case for sadism: Maven.