Moving from Grails to Spring Boot part 1: the man in the middle strategy
Out of our 10 back-end services, 3 are running on Grails. They are the oldest services of Whoz and started before we decided to shift to vanilla Spring Boot. A year ago we began to actively migrate those Grails services to Spring Boot, here is how we did it.
Small steps
The first thing that drove our strategy was the need to migrate the services in small steps, to be incorporated in our feature delivery sprints and our technical debts reducing sessions, faithfully to our Kaizen philosophy.
The difficulty comes from the all-in-one nature of Grails. For example, if you want your GORM entities and queries to open database sessions automatically, you have to come from a Grails controller. These entanglements in the framework were the main cause of the failure of previous refactoring attempts. Trying to change a tiny part leads to truckloads of modifications, that become too risky or too big to fit in a sprint.
We came to those conclusions :
- GORM entities must not be tied to each other, so they can be migrated independently from each other.
- Service and controller layers of apps must be GORM agnostic, so they can be migrated independently of other layers.
Make entities independent
This part is quite simple and was the first we did. All we had to do is to replace one-to-many relationships designed in GORM with simple IDs. Note that we use MongoDB as a database, and a good part of the team was already not fond of tying entities through relationships in the ORM, so this change was a blessing anyway.
Concretely, two entities declared like these:
would become
Isolate GORM behind a repository layer
Here is a typical Grails service method to find a Person by first name.
To cut ties with GORM, we create a PersonRepository interface that is injected and used in the service instead of Grails-generated static methods on the entity.
Actually at this point, using Spring Boot for our person service is trivial, so let’s just put a @Service annotation on it and that’s it, our person service has been migrated to Spring Boot!
We are not done yet though, this repository interface has to be implemented and for now, we’ll keep GORM to do it. Our objective in this first part is to isolate GORM, so it can be replaced seamlessly later.
There are two essential things to notice here.
Firstly, the class is named PersonGormRepositoryService because the Service suffix is required by Grails.
Secondly, we wrap the Person.findByFirstName() call with Person.withStatelessSession so a session is opened before the query and closed right after, ensuring a MongoDB connection is available and the GORM query cache is flushed and committed. Remember, Grails handles a database session only if we come from a Grails controller and a Grails service. We already have switched the person service to Spring Boot, so we need to handle sessions in the GORM repository.
Smaller pieces to be spread out
By cutting ties between entities and migrating the service layer first, we divided our problem into small pieces that could be incorporated gradually into our sprints.
Once every service of an app has become a Spring Boot one, we can choose different paths, like migrating each controller one by one, or each GORM repository and entity to Spring Data, or a controller for an entity, then its repository, and moving on to the next entity.
This is what I called the “man in the middle strategy”, we started by working on the central part (the service layer) and isolating the others so they could be worked on at different times, by different teams.
If you enjoyed this reading or if you are also migrating from Grails to Spring Boot, I’ll soon publish new articles on the topic where I’ll share some tips about migrating a controller or a GORM entity.
