Java/JVM ecosystem is extremely mature and vast. It comes with a palette of production-ready choices for libraries solving problems that we face developing all kinds of services: be it from logging/metrics to async messaging or access to all the major sql and nosql data stores. Add the big talent pool (Java is very often used as the programming language used during CS-courses)[1] and it’s no wonder that this particular language and ecosystem is on the top or among the top 5 in the programming language statistics [2][3].
Having said that, I often feel that there is a certain fatigue when it comes to choice of the application framework. For me it seems that a lot of teams or even companies land on Spring without questioning if it’s actually the right tool for the particular task and what would be the alternatives. This is even more puzzling as microservices become a more and more popular architectural style and that IMHO changes a lot of the requirements one has for the app framework as e.g. memory footprint and startup time become way more relevant.
This post is by no means intended to say Spring is a wrong choice or something along those lines. It’s more a call-out to look at other alternatives in that space that may be just smaller, simpler and offer a more light-weight approach. And there is something to be told about the more light-weight approach too: It’s been a while that I’ve seen a team that truly understood all the batteries that are included in Spring and did not struggle from time to time with some of the concepts that are in play. Hence, I wanted to take a closer look at some of the other options that are around the block by implementing a small service, that is not so far off a real scenario: consume messages from a queue, aggregate certain information exposing it via an REST endpoint and implement it using spring and others. All code and exact numbers can be found in this repo. This post will be growing as I will be adding the result of my little experiment one by one over time. In the end it will be a summary of what I’ve discovered along the way and what you may also find interesting.
So let’s look at the options?
All the options that I ended up taking into consideration address the changed nature of the systems that we write by switching from reflection-based approach to a compile-time based approach. They also support creation of native images thanks to GraalVM which makes the result both impressively fast to start and also very small. The tradeoff here is the duration of the compilation time. I will be looking at:
If I managed to at least catch your interest, then watch the repo and this space for updates.