Top 5 reasons why you should consider Groovy and Grails for your enterprise software architecture right now

I’m so amazed when I see how so few companies are using Groovy and Grails right now, and are still using old stuff like Spring and Hibernate, that I thought I would jump in and do my share of educating. And why not give in to the fashion of top lists while I’m at it? So here it goes: if you are an enterprise software architect and you have a lot of Java in your world, you might want to read carefully what follows.

1- Grails really IS Spring and Hibernate (with sugar on top)

I said earlier that Grails was a good replacement for vanilla Spring/Hibernate, but it’s even better. Sure the creators of Grails and Groovy were envious of the levels of productivity you could get with frameworks like Django and Rails, but they didn’t just start from scratch. Instead, they reused proven technologies like Spring and Hibernate and built a dynamic convention-over-configuration abstraction layer on top of them in order to really streamline the process. In the real world it means that you can bootstrap a new project very quickly by using default settings, but you have all the power of Spring and Hibernate under the hood, should you need to do some really specific stuff. The best of both worlds! And it also means that you can use all the Spring modules you already love and integrate with all the databases you are used to, without any problem.

2- Groovy is actually Java (on steroids)

Java is a statically-typed language and it was designed to be, because it’s just easier to understand. But recently, we have all come to envy the expressivity and power of dynamic languages like Ruby and Python. The problem is that they are completely new languages, which means 2 things: the learning curve is pretty steep, and it’s hard to find good developers for those languages. Well, fear no more my friend, because Groovy is here to save you. Groovy is essentially a superset of Java as a language, which means that you don’t need to learn an entirely new language, and it’s really easy to turn any Java developer (and there are lots of those on the market right now) into a Groovy developer. Sure Groovy offers much more than Java in terms of power, and it can take some time to get a good grasp of all the ins and outs of closures, dynamic typing or even meta-programming. But the good news is that you don’t need to master all those right away in order to leverage a lot of the productivity you can get out of Groovy.

3- And it runs on the JVM

And it gets even further than that: Groovy is so Java-rooted that it actually compiles to run on a Java runtime. Yes, you heard me right: Groovy code compiles into JVM bytecode, which means you can still make Groovy and Grails applications run on your favorite application server (simplest is Tomcat, but I’ve made it run on JBoss and even Weblogic) AND you can reuse all the awesome libraries available in the Java ecosystem in an instant. Just plug your environment with your Maven or Ivy repository of choice, or copy some JARs over and you’re good to go! How amazing is that?

4- Groovy is not just for scripting

I mean sure, Groovy is great for system scripting, in the same way as Ruby and Python are. Not everything needs to be a class so you can write scripts in no time. But a lot of people use Groovy just for that, and think it’s not ready for prime-time big-fuss applications yet. But did you know that most of Sky‘s software (the British broadcast network) are built with Groovy and Grails. And let me tell you: we’re not talking about small stuff here. Big demanding environment! Yes, Groovy is a dynamic language, which also means that there is a lot less stuff checked at compilation time than with mere Java, but since your code is much more expressive, there is a lot less opportunity for errors too, and unit tests are a lot easier to write, especially thanks to DSL’s.

5- A very dynamic ecosystem

Every experienced developer knows that a good framework is nothing without good documentation, serious support and a large community of contributors. Well, of course Groovy and Grails have all that. First of all, they are part of the portfolio of SpringSource, the very company that brought you the Spring Framework and that is now a division of VMWare. So if your company won’t consider a technology without a good support contract, they have it all figured out. The documentation is really good, like most Spring documentations by the way, and there are some excellent books out there. As for helpers and contributors, whether it is on the mailing list or on StackOverflow, helpers are everywhere. And in terms of ecosystem: Grails has a plugin mechanism that makes it really easy to extend the framework in a lot of different ways. Now I won’t lie, all of the available plugins are not necessarily supported or kept up-to-date on the long run, but they are so easy to write and fix, that it’s not really an issue.

 

So what are you waiting for? Why don’t you try it? Do you need some help? Because if you do, it just turns out that I’m a big fan of Groovy and Grails myself and I’m currently looking for freelancing missions so I can definitely help you with the transition, or at least with a proof-of-concept, like I have already done it numerous times. If you are in Belgium, especially around Brussels, or willing to let me help you remotely, feel free to get in touch. Like drug dealers, first dose is free…

13 comments

  1. 4 bis – Groovy is not just for testing…
    Although it’s doing a great job at it, with plenty of great fwk around it.

  2. Well mr. Sébastien, grails has it merits: it screams productivity with a thump, hands down! I adore the pattern of ‘let’s get it done’ oppose to mind boggling syntax aka java meets hibernate on XML that will fry your brains out (a single typo sinks the entire universe into a black hole).

    On the dark side, it needs more plugins from some big names that would complement the likes of hibernate.

    I developed an app that would have taken weeks but with grails it was literarily days. However, it’s not in production (one step minus deployment) till then I need to justify it with my blessings… So far Grails is indeed an alternative to the traditional vacuum available.

  3. Grails leaves quite a bit to be desired as far as ease of use. There are too many details left unexplained to truly be useful in a production environment. The lack of real world examples of the code in action makes Grails something for the water walkers of the world.

    More companies would embrace Grails once it demonstrates its usefulness in a comprehensive manner.

    1. That’s an interesting point you’re making. Do you have any example of such a demonstration for another technology or framework that could be used as an inspiration to do the same for Grails? Also, can you elaborate on the “details left unexplained” you mention so that we can maybe fill the holes?

  4. You can loose all your productivity gains when you upgrade a project from one version of Grails to another. Projects are living organisms that morph and evolve. They need an infrastructure whose versions are backwards compatible in order to prevent the nightmare of using multiple Grails versions for each major component.

  5. Groovy/Grails/RabbitMQ/Spring are all in one place with Pivotal software now. Gives a big boost in market.

Leave a Reply to Vipul Chauhan Cancel reply