Grails in large projects – Part 1

It was in summer 2012 when we discovered Grails as a framework that could be for good use in our web projects. We first did some internal projects to avoid too much risk and then started with our first customer solution with Grails.

We did this project in a bit conservative way, no GORM, data is fetched from Apache SOLR and MongoDB, the whole backend and business logic is written in Java, embedded as a JAR file into the Grails application. Grails “just” renders the results, so we used controllers, gsps, taglibs, all that stuff and were very happy with that, so was (and still is) our customer.

Then we did some smaller projects, using the full Grails stack and we were impressed about the possibilities we have with GORM and scaffolding. Also our customers couldn’t believe how fast we could deliver fully functional prototypes and even lead those smaller to medium projects to a successful end.

Still I believe that Grails’ slogan “The search is over” is not far away from the truth, but most probably only for smaller to medium projects.

In March 2013 we started our first bigger project with Grails, up to 10 developers are working simultaneously on the code (backed by gitlab, gradle and teamcity of course), by December we had 145 domain classes, 118 controllers and 623 gsp’s. We heavily use valuable plugins like Spring Security, Grails Platform, or LessCSS-Resources, and of course we use Sonar to track and enforce code quality. Last but not least we have 1350 unit- and integration tests.

While the project and the team went bigger, we had the feeling that the enormous benefits we noticed with small to medium projects compared to more traditional technologies like Spring MVC with plain Java where shrinking. And I believe that the reasons for the problems we got over time go hand in hand with the architectural decisions in Grails that make it so fast in delivering smaller projects. Things like GORM and its Active Record pattern or Groovy as the main language make it really hard to implement sustainable solution, although it is possible of course.

Part 2 tells about the issues we have with GORM, Hibernate and Transactions.

Stay tuned!

Vorheriger Beitrag
Catalysts Cluj – New Office Opening
Nächster Beitrag
Grails in large projects – Part 2

Related Posts

No results found

2 Kommentare. Hinterlasse eine Antwort

I’m looking forward to the detailed follow-up

With our applications with a total of ~40 domain classes, we’re still well within the comfort zone of Grails development, but things are growing 😉

In your follow-up posts, I’d be specifically interested in
– what’s your experience with server startup time (it usually gets to a painful point as projects grow big)
– what’s your approach to unit vs. integration tests? (if the 1350 are mostly integration tests, that’s probably beyond “instant continuous integration”)
– do you use UI tests (e.g. with geb), if so, what’s your experience?


Christoph, thanks for your comment. I will address all those points in the follow-up posts.


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Bitte füllen Sie dieses Feld aus
Bitte füllen Sie dieses Feld aus
Bitte gib eine gültige E-Mail-Adresse ein.
Sie müssen den Bedingungen zustimmen, um fortzufahren