Groovy/Grails as an application solution

I’ve been having some interesting conversations with a colleague concerning the Groovy/Grails stack as a solution for web-based applications. Although I’ve become a Groovy believer, it doesn’t necessarily mean I’ve embraced Grails as a strategy for rapid application development. I certainly understand the attraction, but using one doesn’t necessarily mean you have to use both.

A word about dynamic languages. I know the controversy surrounding this debate but while I have some reservations, I’ve never been categorically opposed to dynamic languages.  I’ve used ActionScript in the past, have fooled around with PHP, am cool with Javascript and like I said, I’ve become a Groovy convert.  I would advocate using it in any JVM-based app.

As far as Grails, there are many positives. In addition to being great for quick prototypes, it’s also great for situations where plug ins already afford a great degree of desired functionality, or super fast development in scenarios without a lot of disparity in functionality between different facets of the application.

The opinions I’ve formed recently are related to my own admittedly somewhat limited experience with the framework and the discussions I’ve had with people and presenters I met at the recent SpringOne 2GX conference. Since Grails is a convention heavy framework, components need to be built within a pre-defined pattern to get the full benefit.  It infers things about what you’re doing based on that.  Some of the behavior is a bit mysterious and is not clearly documented. If you find you need to get outside of the pattern you have to do the work you’d have to do with a configuration-based framework anyway.

The impressions and general feedback I’ve received on Grails seems to follow this general pattern.

  • It can scale with effort and some sacrifices in terms of clarity and organization.
  • It lacks a way to clearly create a separation of concerns (see above).
  • It is convention heavy which can make for a bit steeper learning curve than some alternatives.
  • It can ultimately become unmanageable over time no matter how careful you are.
  • To mitigate some of these created your business components using the Grails-plugin architecture to modularize the application. Kenneth Liu gave a great presentation on how to approach this at the conference.

Anyway, since the conventions established with Grails is not one that is based on a knowledge of any particular business domain, components can get glommed together in the Grails pattern without regard for reuse or organization.  Controllers in particular can quickly become monolithic.  The business domain tends to reflect the physical implementation of the database because of the nature of GORM.  It can certainly work no matter the scenario but there are tradeoffs and I think if things get to that point it’s certainly worth considering a more traditional configuration-based framework.  By the way, when I talk “scale” here I mean in terms of complexity rather than performance.

To be fair, some people have had pretty good success using Grails for simple or medium complexity applications. Still, if I were to start a complex green field app right now, I’d most likely want to use Spring 3.x with a heavy dose of Groovy for the business logic and use Roo to help with the quick start goodness that is a Grails strength.  You’d get the benefit of Groovy within the context of a highly configurable, well understood, and widely used application framework.

One thought on “Groovy/Grails as an application solution

  1. I’ve “changed my glasses” about this topic a bit as I’ve become more familiar with the framework. Some of the issues I mention can be mitigated by keeping business logic outside of the framework in generic Spring Beans (Grails is built on top of Spring after all). See my post about injecting Grails Service objects into spring beans here.

Leave a Reply