I spent a lot of time contemplating this. I have a three year old internal application in production (not huge production, 50 users or so tops) and it's just a headache.
I hate hibernate. I can't explain how much I hate hibernate.
I hate annotation configurations, cryptic XML configurations, the brutally-annoying-to-navigate docs of Spring, and the fact that this app was built before the ease of Spring Boot.
When I first started this project, I had a team of about 3-4 depending on the day as 1 was a shared resource. The project moved along swimmingly for about 1.5 years and then the new fiscal reality set in.
I live in Alberta. I work in Oil and Gas. Both of those took a big hit in 2015-16 and I unfortunately lost all the budget I had to keep my team. My previously shared resource is still here, but has been fully dedicated to other projects so really isn't a resource at all anymore.
I spent about 1 year now trying to continue development of this behemoth. There is a lot of change. A lot of change. This is the definition of an internal software project that is liable to fail.
It was started to solve one problem. Once it was solved management saw potential to expand. We did. It then became a pretty important piece of how we execute work day to day.
Wash, Rinse, Repeat.
Next level of management saw potential and charged my team (literally just me) to add some more functionality. Just to bring it all together.
Let me tell you how well that's been going.
Java + Spring is a verbose beast. Especially when following proper java coding standards.
Coding against interfaces, abstracting out typical actions, separation of concerns
- Models - Definition, DaoInterface, DaoImpl, DaoAbstraction[x]
- Services - ServiceInterface, ServiceImpl, ServiceAbstraction[x]
- Controllers - ControllerInterface, ControllerImpl, ControllerAbstraction[x]
Then there's the configuration to make the stack API friendly...
Jackson and Hibernate (to me at least) were just painful. Super opinionated, not at all flexible.
While I love proper design and coding standards. An agile individual team it does not make.
I already have 5-6 small apps running on the M.E.A.N stack. Small users, high availability, high productivity.
After about 3 days of deliberation, testing, trying to make Spring easier and faster to develop with, I have made a decision to migrate this 30,000 line API from Java/Spring to Node.js/Express.
Obviously, any large scale processing will remain in the Java stack (imports, large calculations, etc) I intend to move all trivial tasks to Node and hand off any of the big problems to a much more focused utility Java/Spring servlet.
This is part 1 in a series documenting my transition. Check back for more as they come!