Yes indeed, Catalysts has moved, but that doesn’t mean we are gone, we just moved to our new website cloudflight.io
together with our partners from Crisp Research to do the same things we used to do in an improved way. We still do great software and we are still great people, more or less only the color has changed except from our domain 😉

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!

Previous Post
Catalysts Cluj – New Office Opening
Next Post
Grails in large projects – Part 2

Related Posts

No results found

3 Comments. Leave new

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?

Reply

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

Reply

Leave a Reply to Field engineer Cancel reply

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

Fill out this field
Fill out this field
Please enter a valid email address.
You need to agree with the terms to proceed

Menu