Why use Grails?

16 / Jan / 2011 by Deepak Mittal 13 comments

Last week, I was talking to a prospective client, who instead of asking me, why we should go with TO THE NEW, asked me, why should we go with Grails? Considering the fact that I have been working with Grails for over 3 years and we are a Groovy/Grails focussed shop, it should have been an easy question to answer; but there were so many things that didn’t strike me when talking to the prospect; and explaining to him, why Grails is a good choice.

So, I decided to list-down the reasons why I think Grails is great!

  1. Based on battle tested and proven Java frameworks (Spring, Hibernate, SiteMesh, Quartz, etc) : Now, Grails itself has been used by a lot of big enterprises and products such as Sky, LinkedIn, WalMart, etc and Grails is no-longer new; but if you consider the underlying technologies, then they have been in existence for almost a decade (I think) and have a very huge user base.
  2. Based on Groovy language : Groovy code is much more concise, expressive and DRY than Java code, which means there are fewer lines of code, which translates to much higher developer productivity and less code to maintain.
  3. A very responsive and supporting community and mailing list : Grails is not only about technology, it has a very responsive and supporting community. There is hardly any question that doesn’t get answered on the mailing list.
  4. GORM : GORM  provides a very easy-to-use and flexible layer over Hibernate and few other non-relational Data Sources.  This makes it extremely easy to talk to any GORM supported Data Source. GORM supports all relational databases which are supported by Hibernate (JDBC); and it has recently added support for few other Data Sources such as Redis, MongoDb. Support for more Data Sources such as Google Big Table, JCR is expected to be available soon.
  5. Doesn’t stop you from using the power of underlying frameworks : GORM does a good job of shielding you from dealing with Hibernate directly. But at the same time, if you want to bypass GORM and directly use hibernate API, map POJO/POGO to existing tables, then it does not stop you from doing so. Similarly, you can use the underlying power of Spring if you were to do so. Similarly,  you are not forced to use Groovy, you can choose to use Java or stronger typing wherever you want/need.
  6. Easy to set-up and get started : It is very easy for a Java developer to get started with using Grails; and start experiencing the joy of web-application development with Grails.
  7. Domain Centric approach towards application development : Grails puts domain classes at the center of the application, which IMO is a very good thing.
  8. Minimal server restart required while development : While developing with Grails, you don’t need to restart your web-container after making every small change. It uses an intelligent mechanism to reload and apply your changes. (There are still some cases where Grails requires container restart, but such cases are reducing with every release).
  9. Standard Project template and artifacts : Grails projects are easier to maintain because of the naming conventions and standard project structure. Conventions and standards make it very easy for new developers to quickly get familiar with the code and get up to speed on any existing Grails project.
  10. Testing support baked-in : Testing is a priority and first-class citizen in Grails. Grails promotes testing; and provides utilities to make testing easier — from low level unit tests to high level functional tests. In addition, Grails is not married to a particular testing framework. You can use JUnit, Spock, EasyB, Geb, Selenium, Canoo etc. Any testing framework can be made to work with Grails (by writing a plugin that hooks testing framework with Grails testing infrastructure).
  11. DRY / Convention over Configuration / No painful XML configuration & XML Management : You don’t have to write all of the plumbing/boilerplate code yourself when using Grails. This allows the developer to spend more time on writing code for developing features rather than struggling & configuring the framework components. Grails uses convention over configuration, uses sensible defaults and auto-wires based on simple naming conventions.
  12. Scaffolding : Scaffolding utilities provided by Grails is a great advantage when building prototypes to validate the idea; or to build Admin interfaces. For a lot of new developers evaluating Grails, scaffolding is the first thing that brings the “wow” effect.
  13. Clear separation of “environments” : The concept of Environments is a first class citizen in Grails. Grails allows you to easily manage environment specific configuration as part of the code base. For cases where you don’t want to store (for example, production environment passwords) environment specific configuration in the code base, you have the option of externalizing the configuration as well.
  14. REST support built-in : Grails provides built-in support for REST via URL Mappings, Data binding and rendering of objects as JSON or XML.
  15. Tag Lib Authoring mechanism : Grails makes it quite easy to modularize and reuse view layer code; especially because of the ease with which tags can be created. It is as easy to write a tag in Grails as it is to write a Java or a Groovy class.
  16. Data binding using command objects: Grails makes it a breeze to consume and validate form data; thanks to data-binding feature, command objects and the support for validators in Command objects.
  17. Integrates easily with already written Java code : Grails/Groovy integrates easily with code already written in Java. You can even intermix Java and Groovy code in the same file and it will work just fine. On one hand, it allows a Java developer to start using Grails very quickly; on the other hand; it allows use of already written Java code. I have been part of 2 applications, which initially started as a pure Hibernate + Spring MVC application, but were later moved to Grails. In such cases, we didn’t really have to throw away the already written code; and could just build on-top of already developed functionality.
  18. Plugin based development approach for modularity and reuse: Grails promotes reuse of code between different Grails application by modularizing your application in the form of plugins. Taking a plugin-centric development approach promotes and forces clear separation of concern and easy reuse.
  19. Tons of available plugins : Grails has a huge number of plugins which have been contributed by the core development team and other Grails application developers. More often than not, if you want to integrate an existing framework or use an API, you will find a plugin to make the integration much easier.
  20. Hundreds of small things that make development fun with Groovy and Grails : Can’t explain this, in order to understand this, you need to develop with Grails for a week and you would know 🙂

I am not suggesting that there are no pain-areas when working with Grails. There are few pain areas (plan to cover that in a future post); but they are very few and the advantages far overweight the pain-areas.

Besides the advantages covered above and the pain areas (that I plan to cover later), few area about which I have mixed feelings are:

  1. Scaffolding : Grails scaffolding gives you a good start, but doesn’t take you very far. There really hasn’t been much progress in the Grails scaffolded code since Grails came-out. Grails does allow you to modify the templates based on which the scaffolded code is generated, but the default scaffolding templates could definitely be better.
  2. Plugins : The number of Grails plugins that are available is huge. They do provide a lot of functionality and components out of the box. However, not all plugins are “quality” plugins; and not all of them are bug-free & actively supported & maintained. Some of them are too bloated. There are different plugins available to do the same thing. Sometimes, I do get  a feeling that I was better-off building the functionality from scratch myself; rather than spending the time to evaluate plugins and then using a particular plugin & finally giving-up after finding bugs/limitations in the plugin. Grails Plugins Collective is a great step to address this.
  3. View Layer Code : Though view layer code (GSP) is much neater and modular, but still there is duplication and verbosity and it doesn’t seem very DRY.

I have tried to cover some of the Grails gems (no pun intended!) that I value.  I am sure that there are many-many more that I would have missed.  I hope to make it more complete after getting some feedback & doing some more thinking.

Cheers!

FOUND THIS USEFUL? SHARE IT

comments (13)

  1. Chris

    I know this an old post, but it still comes up quite high in Google’s search results when looking for opinions of Grails. I want to add a real world experience for using Grails in one of the largest B2B travel companies in the world. It proved to be a major disaster, thanks to the following:

    1. Bugs and instability in Grails itself that were rarely resolved in newer releases.

    2. The incomplete nature of Groovy (scoping for example), and the way it is not a true superset of Java (the equals() versus == behaviour for example).

    3. Major breakage between even minor versions of the framework, and wholesale change that made upgrading from an initial version unrealistic for any sizable project.

    4. Poor tooling (STS) with little support for effective refactoring.

    5. Most plugins are incomplete or break if not used on a specific version of the framework.

    6. Too much evangelising of the dynamic features, which results in too much fragile code in the wild that is unfathomable thanks to a lack of type information.

    That just scrapes the surface. For me, I’m glad I got out before the whole edifice collapsed (to be replaced by a conventional Spring and Java implementation).

    Reply
  2. claudiu cosar

    i managed to create a simple crud webapp in just 30 minutes. now show me this in java….
    this is a wonderful framework for someone who migrates from java.
    i am a java developer, and initially i was interested in learning more about grails, then i discovered that groovy is so fantastic, that it catched my eyes, and started learning more about the idiomatic style groovy offers over native Java.
    Grails has a LOT of plugins, on their home place; and starting from grails 2.0 there’s involved html5 as well.
    I enjoy learning more about these DSLs…

    Reply
  3. Fadi Samara

    You mentioned “tons of available plugin”! there are just few plugins in the grails website! where the tons come from?

    Reply
  4. Chugh Robin

    I was looking for something like – why not use Grails and it was promised to come but i guess never came.

    Reply
  5. Fabien

    Hi Deepak,

    I really like your article and I cannot agree more with the pros and cons you have described.
    Concerning scaffolding, it is just too bad that this area is not improved by Grails future releases. It would have taken us so far 😉

    Reply
  6. Matthias

    Great post! I personally like to put it the other way around and ask why not use plain Java 🙂 Then it becomes obvious that all the pain you get for free when setting up a project manually, selecting frameworks, configuring them and so on, and so on… and writing all that XML by hand (my eyes bleed when I write and read XML)… Man, I’m so over those times 😀

    Reply
  7. Michael Morett

    Been using Grails for a few months now after years of Java and it’s been nothing but fantastic. Huge fan of the Grails in Action book and The Definitive Guide to Grails. Just wish more jobs were available using it. Rails is getting all the fun work.

    Reply
  8. PSY

    @Matt – Our company builds apps in both Rails and Grails for our clients. What I can tell you is that we have a Grails web app in production that typically has around 6-700 active sessions during peak hours and whose largest database table is just shy of 1M rows. Yes, there were a few queries we had to de-GORMify and in one spot we’re even using Redis, but those are changes we would’ve had to make with almost any framework.

    There was a time when our standard stack was Spring, Hibernate, and Wicket. None of our engineers miss those days.

    Reply
  9. Deepak Mittal

    @matt, I have experience with a number of live and high-traffic (few million hits over a weekend kind-of) web applications. Grails app is as scalable as any other Java application. We have few project which are running for more than 2 years; & I can tell you from my experience that it is much easier to maintain a Grails project over a long period (with team changing over time); because of the fact that Grails projects have a standard convention & Groovy code is more readable and expressive. Having tests of-course is very important as with any other framework/language.

    Regarding your concern of missing hidden features, are there any specific underlying features that you can’t use with Grails?

    Reply
  10. Graeme Rocher

    @matt “Grails does miserably there” – Tell Sky.com that who server 100 millions of requests per month with Grails (or Walmart, or Manymoon or etc.)

    It is also perfectly possible to refactor a dynamic language codebase, folks who don’t understand this are either:

    a) Not writing tests

    or

    b) To used to being handheld by their IDE

    Reply
  11. matt

    Not my opinion.
    Grails seems like a nice playground. However, doing “real world” applications in larger teams over more months, the control grails gives you over your webapp is just not enough. You’re missing a lot of the hidden away features. Especially as many of the “grials features” don’t scale well (Gorm in particular).

    It’s nice when you have a website with 100 visitors/hour and some thousand records in your DB. But what about 100 visitors/second and 100.000s records in DB? Grails does miserably there.

    Another big problem is refactoring – hardly possible with grails, because it’s a dynamic language.

    Reply
  12. Deepak Mittal

    @Richard, not sure what you exactly meant when you say “problem for large enterprise systems” : is it the usage of Groovy or achieving 100% test coverage.

    I agree that testing becomes even more important with usage of Groovy (or any other dynamic language).

    Reply
  13. Richard

    Because Groovy is dynamic language, I will need for important projects 100% test coverage ?? It could be a problem for large enterprise systems ?!

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *