One year after Part 2 I finally took the time to write this third and last part of this series; not only because we’ve continued to make further experiences in this area, but also because I got asked by many people that couldn’t wait for this additional blog entry.
So let me share our experiences with you folks.
To put it short after using Grails for 3 years now: We wouldn’t use it for bigger projects any more.
I would say Grails has four major design problems, that really come out to the bad in bigger projects:
- GORM (I’ve talked about that in my previous entry)
- Groovy (you could come across that partly by using Java, but not everywhere (e.g. in Controllers, Taglibs and around GORM)
- Test support (unit tests behave different as in production, built-in integration test support forces you to ramp up the whole application context…)
- Lack of modularization.
So let’s talk about the latter. Yes, Grails supports plugins. But that’s not the same as modules, at least not in my mind. Modularization means me for:
- Separate backend from frontend; also having the possibility to start the application without the frontend
- Separate business modules from each other
- Reuse controllers for different output formats (e.g. HTML and JSON)
If you try to do those things with Grails, you really run into problems. Grails’ plugins are designed as reusable units (like the one for spring security), configurable and with plug & play support; but not to modularize your application. It’s hard (sometimes impossible) to create modules that give your some basic support of your application (i.e. user handling, authentication, admin backend) and hide that such, that your application developers can use it but not break it. Groovy makes everything public by default, so if you are having a GORM entity in one of your plugins you cannot prevent any one in the main application to save or delete that entity. Everyone can call entitiy.save() from anywhere.
Especially when you are working in bigger teams, this is really a problem.
If you do not need all of that stuff and you are fine with monolithic web apps, then you will most likely be fine with Grails. Otherwise, go for alternatives.
I’ve talked about the problems that come up with Grails’ Active Record Pattern already in a previous blog post, I won’t go into further details here.
We’ve also implemented Grails Apps without GORM, so that is not a big issue, you can easily come around it.
Hard to describe here. But what we have seen, is that the continuous build becomes unstable when you reach a code base of about 100,000 lines of code, having some 1000 test cases. Some times tests fail, some times they pass. It’s not deterministic any more, and we had to @Ignore many tests that were randomly failing. Unfortunately it’s really hard to track that down, and thus also hard to file any issues. I just can tell you that those problems started to come up when the code base grew.
As I’ve also already explained in a previous post, the IDE support especially of Intellij IDEA for Grails is really great. But that one has limits as well. As everything is dynamically typed, the IDE has lots of more to do to provide content assist, compiler warnings, code completion, and so on. When the code base grows, the IDE slows down. Don’t get me wrong: We are working on the best hardware you can actually get for money, but even with that infrastructure the IDE starts to freeze over time even when doing simple operations. We have much bigger plain Java projects and never had those issues.
At CORE we started development with Grails 2.2, at some time we upgraded to 2.3, but now we are stuck at 2.3.6, although the latest version is 2.4.2. I can remember switching from 2.2 to 2.3, and that was really a pain in the ass, many things were not compatible any more, and some things (e.g. validation handling) really changed to the bad. We had to write our own logic there to ensure that our existing application is still running fine.
So if you are implementing a web application once, then deploy it, then probably do some minor fixes over the year, then you are fine here. But in real business scenarios, not having the possibility to upgrade your underlying base libraries can really hurt. Especially in Grails, where this also restricts you in upgrading major frameworks like Spring and Hibernate.
Does that mean we do not use Grails at all any more?
No. There are still occasions where we know that the projects will never reach a certain size but where the budget (in time and money) is very rare (which is almost everytime the case…) and where it is important to deliver fast solutions. Applications that mostly do some CRUDLing. Take Grails for those projects and you and your customers will be fine.
What does that mean for existing projects that we still maintain?
If you’re one of our customers running projects written in Grails, then you might be scared now. No need to do so. We’ve managed to get around all of the pitfalls, we know how to handle the issues, so no existing project is in danger. We just learned from the past and wouldn’t want to have those problems in future projects any more.
Why didn’t we change anything?
So well, Grails is open source, its JIRA is public, and everyone is free to add issues or even submit pull requests. To be honest, I didn’t take the time to clone Grails’ Git repository, study the internals of the framework and then participate, but at least I filed 14 JIRA issues , 8 of them still being open at the time of writing this article, most of them around GORM.
And some of the issues have only been fixed on the latest versions (2.4.x), so no way for me to benefit from them as I (as mentioned above) could not (easily) upgrade from 2.3. That made also kind of concerned.
The future of Grails
Now, if you read blog entries from the Grails development team, thinks should go better with Grails 3. Gradle comes in, there will be a tight integration with Spring Boot, and modularization support should evolve. As we will continue doing smaller projects with Grails we of course will follow that development.
Besides that, I also wanna express my appreciation to the development team of Grails. I still consider it as a good rapid development framework – if you know its limitations.
So what are we doing now with our big projects?
No worries, we have plan that proved to be successful. But that will probably be the content of one of our next blog entries.