For those of you that have not come across the
Grails platform, I would seriously encourage you to do so. Particularly if you are a web developer. If you're
not a web developer, then hey, it's probably not that interesting for you.
Grails is built on top of the
Groovy language, which itself is built on top of the Java platform. It shares some design principles and a philosophical orientation with
Ruby on Rails, but it is its own discrete platform (and because it is so closely related to Java, it is nowhere near as intimidating for someone unfamiliar with Ruby).
I won't bore you with repeating the details of either technology, because the best thing to do is go to those links above and check them out for yourself. What I want to do in this post is highlight 2 things that I think really make these technologies compelling:
- Model bootstrap time
- Web development cycle time
Model Bootstrap TimeLet me begin by stating that before I embarked on my current project (a web-based work-flow and process improvement tool for a niche vertical) I had not programmed seriously (as in "on a development team, responsible for deliverables") for more than 3 years. In that time I had managed an engineering team and worked as a CTO, so I was across the technology landscape, just not in the kind of detailed, on the metal way that you are when you are actually writing code.
When I began to look for a platform to build my project, I checked out a variety of different options. First up was what I already knew, which was basically standard Java and J2EE. I though that through, and along with my business partners, made some estimates for development time. These numbers were pretty big, in fact they were probably too big for our resources and timeframe. This led me to have a look around for some alternatives.
My first port of call was
AppFuse.
Matt Raible has done a brilliant job integrating the daunting suite of Java tools, libraries and technologies into a coherent whole. With very little mucking around, I was able to have a simple application stub that allowed me to log on, manage users in a database, complete with
Hibernate and
Tapestry support, all running very sweetly out of
Maven2. My issue with this, however, was not how quickly I could get up and running (which to be fair, cannot be much quicker!) but what to do
next. Even though AppFuse wraps everything up, you still need to have a very good understanding of the architectures and idioms of the constituent parts to actually do anything of interest. And there is a
very large software stack that underpins the prototypical AppFuse web application.
This is when I stumbled across the Grails project, just about the time it was released as Grails 1.0. I read the tutorial and quickly came to the conclusion that it would be simple enough to prototype the domain model for my new system using Grails. Which is what I did. After downloading all of the various Eclipse plug-ins, I was writing Groovy code and building my new system.
All up, I think I spent about 5 days on and off over the space of 1 month (note: this is a side project I'm working on, and not my full-time job) putting together the domain model. During this time, two pretty amazing things happened. Firstly, Grails has the concept of
scaffolding. Until you have seen this, it sounds a bit like magic. Through the use of the
configuration by convention idiom, Grails scaffolding allows you to get basic CRUD operations across your entire model (more or less)
for free. This means that you can define a simple model class like this:
class User implements Serializable {
String username = '';
String password = '';
String email = '';
String mobile = '';
Date created = new Date();
// Relationships
static hasMany = [roles:Role];
// Constraints
static constraints = {
username(unique:true,blank:false);
password(blank:false);
email(blank:false);
mobile(blank:false);
}
}
And then run the application and work with the new domain object, creating, editing, updating and deleting them (assuming you also define the companion Role class referenced). Again, I won't go into the syntactic details, which can be easily discovered in the Grails reference manual. However the standout feature of that code is the complete
lack of gumpf associated with the platform. It really does present a crystal clear example of what a POGO (plain old Groovy object) should look like.
What all of this means is that you can build a working domain model
incredibly quickly when compared to the traditional Java approach. There is literally nothing else to do other than build the objects and attributes of the things that are in the domain model.
As an aside, I will mention that it took me a little bit of time to get my head around the
configuration by convention idiom. When you start out, there is a lot of automagic stuff going on, and it can be a little difficult to let go and just trust the platform. However, once you do, the results are startling.
2. Web development cycle timeThe second most extraordinary thing for someone who has not built a web application for the last couple of years was how different the development cycle time is with Grails. With a properly configured environment, the time it takes to make a change to a web page and see that registered in the application is roughly the time it takes you to make the change in the editor and click Refresh in the browser.
The spectacular thing for me was that this also works for (most) code changes. You can add an attribute to a Groovy object and then click refresh in the browser and the change will be apparent immediately. There are 2 exceptions to this. Some changes require the web container to go through a bounce process, but it is generally only marginally slower than a simple text change in .gsp page (GSP: Groovy Server Pages, like JSP pages but for Groovy code). And then there are some code changes that stretch this capability to the limit and will require a restart of the container, but these are rare.
This is an amazing difference when compared to earlier generation web development where you needed to rebuild the war and redeploy it to the container, then re-establish the session to the point you were up to in the test cycle. It could easily take many minutes to test a simple change. With Grails, more often than not, you just continue in the same session with the updated code running. No need to restart. Brilliant.
ConclusionIn combination, the speed with which I was able to prototype and work with a domain model, and the vastly reduced cycle time for the edit/compile/deploy/test cycle mean that I have been able to get started and then
be productive more quickly than I could possible have imagined. When I use Grails and Groovy now day-to-day for development, I get the same kind of back-of-the-neck feeling that I got when I first saw Java back in its 0.9beta release in 1995. This is something special.
