grails

Grails – Somebody That I Used to Know

Grails – Somebody That I Used to Know

“I left Grails as an esoteric, and somewhat immature framework, only to find it again, years later, as a solid, predictable, and well put together platform.”

By Simone Pezzano

Back in the day, the adoption of an application framework that could provide tooling for an enterprise application was not in question. It wasn’t because developers, like me, had no alternative, but simply because the amount of work ahead was impossible to finish without the help of a fully featured platform. But I had to accept the compromises of adopting a beast to get the level of support I needed.

The most logical solution seemed to be Grails, a relatively young application framework for Java and Groovy. The stack was familiar, checked all the boxes, and definitely introduced a high number of shockingly advanced features such as its very unique ORM written on top of Hibernate.

There were, however, things I didn’t like about it – most of all, its esoteric approaches to a number of tasks. For the most part, it worked well, even though many of the things it was doing were mysterious. But when it didn’t work well, debugging could be a complete nightmare.

When Grails’ new major versions were released, I soon realized that the Grails team was doing more than just upgrading one of my favorite toys; they were rewriting it, and in doing so, they were unwittingly introducing more and more obstacles to migrating our code. I was not confident that my team and I would have enough time to deal with the changes.

So it shouldn’t come as a surprise that while getting ready for our new Mastiff 2 initiative, I looked at my old pal, Grails, with a little hesitation. Maybe Spring Boot with its plugins could serve in the role occupied by Grails well enough, and fill all the gaps that come with such a radical decision.

It would have been irresponsible, however, to simply dismiss Grails on the get go. While some backward compatibility was certainly lost, a lot of it was definitely maintained and, after all, the new Grails 4 is not the Grails 2 that I used to know.

I left Grails as an esoteric, and somewhat immature framework, to find it again, years later, as a solid, predictable and well put together platform. The funky build process has been replaced by a standardized Gradle build that pulls together all the components that I could possibly need in a very elegant, tidy manner. In fact, you can immediately tell things have improved drastically based on the shorter build/bootstrap times.

The new Grails 4 is not the Grails 2 that I used to know. Years later, it is a solid, predictable and well put together platform.

Grails 4 is built on top of Spring Boot. As the standard for teams that want to start microservices small and then iterate quickly, Spring Boot is possibly the top choice to create Java-based microservices. In Grails 4, GORM (our beloved ORM) is still there, now based on Hibernate 5, as well as GSP (Groovy Server pages). Most of the configuration that used to be programmatic can now be replaced with comfy YAML files, while still allowing programmable configuration. Also, extremely important for me, is the full and systemic access to the dependency injection provided by Spring through its classic annotations. While this sounds pretty obvious, it wasn’t really the case in Grails 2.

Grails Views for JSON is really something that impressed me a lot as well. After all, the new Mastiff 2 platform will interact with the rest of the system solely via APIs, and this tool could definitely expedite the process of creating and maintaining them.

The new Mastiff 2 platform will interact with the rest of the system solely via APIs

But even more than the features breakdown, it’s how the framework feels. Solid, predictable, featureful, maintainable, and with a (finally) reasonable resource footprint.

Combine these factors with the huge amount of existing code that I want to port, and the choice to use the much improved Grails 4 is inevitable.