So we’ve been busy at work for the last six weeks building a new version of our software that will run as a web application. I can’t link to anything about it yet because it’s not finished, but we’re already having fun trying out new stuff.
One of the biggest new things that we’re using is Grails. Grails is a neat web application framework that builds on the well-known enterprise Java stuff like Spring and Hibernate. It also uses the Groovy language.
Obviously jumping into something like this is a huge change. It has meant that we have had to redesign the whole system so that it fits the framework and we’ve had to change the way that some stuff works. It’s not often that you get the opportunity to completely start from scratch to build a new version of software.
One of the reasons why we were able to justify doing this is that Grails is such a brilliant environment for rapidly developing applications. For example, we have been able to pretty much build a system that functions and could be useful within just a few weeks. Obviously there’s still an awful lot of polish needed before it can be put in front of paying customers, but with Grails we’re able to get to that point much more quickly.
Also, from an engineering point of view, Grails is a lot neater to work with. It uses the model-view-controller paradigm from the off and pretty much forces you into sticking with it. This is good engineering practice, particularly as we are able to much more explicitly segregate application logic and view rendering and the domain model.
Another important advantage for us is that we can reuse a significant proportion of our existing code that was written in Java. Groovy code compiles to the same Java bytecode and runs in a normal Java virtual machine. This makes integration of Java and Groovy code a doddle.
Groovy has a huge pile of features that can improve developer productivity. For example, it introduces untyped variables, closures and lists/maps as explicit syntactic entities. It is also totally object oriented - all the primitive types are now used as their class equivalents. It looks a bit strange to be calling a method on a number, but this is now quite useful. Groovy makes querying the database a trivial activity - dynamic finder methods make it quick to write simple queries or you can use a Hibernate query language (HQL) builder to construct an HQL query if you want more complexity.
Untyped variables are useful in some areas. It makes it useful to just define a variable without caring what type it has. Of course, you can still have everything fully typed if you want - static type analysis at compile time really is a good thing and can’t be ignored completely!
We haven’t yet found uses for all the features of Groovy and Grails - stuff like metaprogramming looks like it may be useful but is not yet necessary for anything that we do. Obviously learning a new language and framework means that after a short time you have to go back and refactor some stuff now that you’ve worked out the proper way of doing things, but even so, we have seen a huge gain in productivity.
The downsides? Well, it clearly new to us, so we’ve had to learn it. And this is on-the-job learning too! Some of the documentation is out of date or not quite up to scratch - this is noticeable as Grails is only recently maturing as a quality framework and stuff has changed a lot up to around a year ago. Grails has stabilised nicely though and we are seeing a continual improvement in the quality and availability of the documentation.
One risk that we considered was that Grails and Groovy were relatively new technologies. It’s clearly a risk that stuff might change or that they go out of favour.
All in all, Grails and Groovy appeared at just the right time that we could get started with them. They have proved a godsend to us and may possibly be the enabling technology that allows our business to succeed.
