Since I sometimes get asked why I prefer Grails, I thought I would list some of those reasons along with some of the caveats.
- Speed of development: Keeping up with the pace of change is a common challenge for any research informatics department. It’s been pointed out numerous times that agile software development methodologies most closely resemble the research environment. This means that you’re often tasked with iterating quickly on a web application — incorporating feedback from researchers every couple of weeks. And I haven’t found a framework yet, that let me iterate as quickly as Grails. Spring Roo is perhaps closest to this, but Roo lacks the number of plugins (see caveats) that Grails has and domain object (entities) specification in Java can be rather verbose in comparison to Groovy (the language that Grails uses).
- Reusability: I often use Java or Groovy libraries in my Grails applications. This lets me leverage BioJava and similar libraries in my application. In most of my applications, I use BioGroovy as a means of integrating public web services like NCBI’s EUtils to access EntrezGene, and PubMed. BioGroovy has a set of models which map closely to the domain objects I use. This makes it possible to do a PubMed search (for example) and save the resultant Article objects into my Grails app.
- Pluggability: One of the nice features of Grails, is the ability to turn a Grails app into a Grails plugin. This makes it possible to take whole applications or pieces of other applications, and integrate them into new applications. I’ve often thought, that if I can find enough time, I’d like to create a BioGrails plugin that people could use as a starting point for their own applications. If anyone is interested in collaborating on that, contact me and we can talk about it further.
- Groovy: Grails uses Groovy as its development language. I’ve found Groovy to be less verbose than Java (even though some of my Groovy looks very Java-like). Anyone who’s done a lot of Java development should be pretty comfortable with Groovy. Groovy also supports a strong-typing as well as type inference, which means that if you have any concerns that Grails might be slow because of the amount of type inferencing that you’re doing, you can always make it strongly typed.
- IDE support: there’s an Eclipse distribution called GGTS (Groovy/Grails Tool Suite) that makes the process of Grails development easier. That said, most of the demos I’ve seen from the folks at Pivotal (the company behind Spring and Grails), have involved the use of the new Grails command line interface. You’ll find a whole host of demos on YouTube Spring Developer Channel.
As with every rapidly evolving framework, Grails has its issues that you should be aware of before you get started.
- Plugins: There are over a 1000 plugins in the Grails ecosystem: everything from security, social networking, graph database & big data support, and charting can be found. Some of the plugin developers do a really good job of keeping up with an evolving plugin spec, others do not. In the upcoming Grails 3.0 release this will be especially challenging as there will be some significant changes to the spec. As an app developer though, this means that every time grails is updated, you should expect to spend some time, evaluating the impact of those changes to your app. The more plugins you use, the more likely it will be that something will break. I use a minimal number of plugins, and I’ve found that the Spring-related plugins tend to break less frequently, in part because they’re maintained by the same company that creates Grails.
- Upgrades: Expect to fork your application and continually upgrade your app. Grails is on a monthly release cycle. If you skip a number of releases, and attempt an upgrade, you can expect to spend some time catching up. Follow the upgrade information closely.
That said, Grails is by far my favorite web framework. In my next piece, I’ll discuss some of the features we can expect in the upcoming Grails 3.0 release and the implications for research informatics organizations.