Why use Grails?

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!