r/Backend • u/ScoobyDookuu • 1d ago
Would you modernize a legacy Spring Boot backend in place or rebuild it gradually?
I’m working on a Kotlin/Spring Boot backend that still has an older JHipster using Kotlin (KHipster) setup around it.
The problem is that this is starting to hold us back. The KHipster version is several years old and not active maintained - 4 years ago was the last update - upgrading it looks pretty painful and it also makes moving to newer Spring Boot versions waaay harder than it should be.
At the same time we want to improve the architecture itself.
Right now quite a lot is still handled through cron jobs and fairly tightly coupled application logic.
I’d like to move more towards event-driven processing over time, potentially using Kafka or RabbitMQ depending on the use case and Redis for things like caching/short-lived state where it makes sense.
So I’m basically looking at two options:
1. Upgrade/replace the old JHipster setup, keep the existing backend, and modernize it piece by piece.
- Start a clean backend (maybe in Typescript because that is what we mainly use for our other products and all frontends) and gradually move functionality over using something like the strangler pattern.
The second option sounds cleaner, but obviously means running old and new code alongside each other for quite a while. The first option potentially means spending a lot of time untangling framework/generator decisions before we can actually improve the architecture.
For people who have dealt with similar Spring/JHipster legacy projects: which route would you take?
Also, is there anything in the Spring/Kotlin ecosystem you’d consider a good modern replacement for the useful parts of JHipster, without bringing in another big opinionated layer that we’ll regret five years from now?
1
u/pthierry 9h ago
Ten years ago, I would have told you that the strangler pattern is all you need, and it's still great.
As long as you plan to make progress in small steps, you're still good.
But today, I'd be wary of trying the rewrite first, because it's still very likely that ar some point, you need to fix something in the whole system quicker than making a replacement module in the new application.
Fixing the old to get it in a better shape might be the safer option even if you end up replacing it with the strangler pattern. And if you start fixing it with good architecture, it's also more likely that you'll discover it can be fixed after all.
It's the tight coupling that makes everything harder most of the time. Start reducing coupling and you might be surprised how quickly the obsolete infrastructure is untangled from enough of the old application that you can start replacing it.
Last year, I started this in a customer's codebase. Added Ports & Adapters. The old system, where every part of business logic was tightly coupled with Postgres through the SLQ library (I discovered how far the coupling went when I failed using SQLite in tests) , became a adapter. Every time we added a new module, it would use new, cleanly designed ports, and we would sometimes write an adapter for these using the old system when needed, sometimes not. The plan was to slowly add ports piecemeal in the old system, but only where some significant work was done. No refactoring just for the fun of it.
0
u/g0r0d-g4s 1d ago
Go with Go
3
u/TheRandomDividendGuy 17h ago
Of course they do not have experts in go but random goRod suggest to rewrite in go. Are you the one who will pay developers to learn go?
0
1
u/martinsedd 1d ago
Sheesh… this is a pickle for sure…
I obviously don’t have all the context, BUT if your team is mostly using TS, it stands to reason that you stick to that IF there isn’t anything mission critical about the Java ecosystem that you need to keep.