The Gr8 Conference: Groovy Usage Patterns
Most of the attendees at the conference would love to use Groovy or Grails for projects, but many companies are still in the evaluation phase. The question Dierk Konig tried to answer in his session was “what are some of the different ways you can introduce Groovy and Grails to client projects?”. He identified seven common patterns for introducing Groovy and/or Grails into projects: superglue, liquid heart, keyhole surgery, smart configuration, unlimited openness, house-elf scripts and the prototype.
1. Super Glue
Java makes a perfect infrastructure layer. With proven frameworks, widget sets and services it can provide a robust underlying layer for applications. Scripting can provide a more flexible and agile application layer on top of the infrastructure layer in Java for pulling together the capabilities of the frameworks into a custom application more quickly than if you were to use Java for the entire application. This approach allows you to build on the strengths of Java but to make it quicker/easier to use for developing applications. It also allows developers to leverage all of their experience in using Java frameworks.
2. Liquid Heart
This is almost the opposite of the super glue pattern. With the liquid heart, you have a well defined application structure developed in Java, but you use Groovy to implement fast changing business rules such as calculation rules for bonus allocations. By creating a clear bounded context, you can then use Groovy to more elegantly express a Ubiquitous Language for implementing the business rules in a particular area of the application. Good candidates for this are areas of the application with complex business rules that change frequently, making them a good candidate for a Domain Driven Design/Domain Specific Language based approach.
3. Keyhole Surgery
Sometimes you just need to be able to see what’s going on with your application and to be able to run code against it that you can modify without having to recompile the entire application. With keyhole surgery, you can create a back door for the live execution of Groovy scripts. This pattern is particularly useful for product support, failure analysis, hot fixes and emergencies.
4. Smart Configuration
If your team is concerned about writing application code in Groovy, often a good starting point is to use it for smart configuration, enhancing configuration with logic and replacing XML files with much more concise and expressive Groovy scripts. By having all of the power of a Turing complete language, you can often express the intent of the configuration much more elegantly and meaningfully than with large XML files.
5. Unlimited Openness
Especially for small to mid-sized green field projects, it can often make sense to go “all script”, creating an application that can be more concise and expressive, whether leveraging Grails or Griffon or just working directly in Groovy. The only proviso I’d throw out with this is that you need to consider the complexity of the application and the maturity and size of your dev team. Larger teams (really more than 3-5 people), relatively new to dynamic languages can get into all kinds of trouble by overusing dynamic language meta-programming features to the point where nobody on the team actually knows how the application works!
6. House-elf Scripts
If you want to get a quick win using Groovy, look at creating ad-hoc scripts. From build automation to installers, service monitoring, reports, statistics, automated documentation, functional tests, html scraping, web remote control, and web services there are lots of ways to get familiarity and to build comfort within your team by implementing these kinds of incidental scripts in Groovy.
Sometimes you just want to do a feasibility study – a quick spike to try out a technology, UI or set of algorithms. Groovy, Griffon and/or Grails can be perfect for those kind of quick prototypes. And if you write them well there is no reason why you can’t either use them in production or port some/all of the parts of the application to Java down the line. For example, at Canoo, instead of a written RFQ they’ll often just build out a sample application to give the clients a sense of how it would work.
In addition, Dierk mentioned a couple new patterns he’s formalizing. The “lipstick” pattern is an increasingly common pattern of wrapping a Java API with a thin layer of Groovy to make it easier to work with and the “ghost writer” pattern describes the times when you use (for example) annotations and AST transformations to enhance a Groovy API by adding functionality using meta-programming.
The session really did a good job of providing a language for describing different ways of thinking about how to introduce Groovy and Grails into projects and hopefully we’ll be able to start to use this language within the community when describing potential adoption strategies to both give us more ideas on how to start to use Groovy and a more efficient vocabulary for sharing our experiences.