I've been working on a "high-performance" Spring Boot WebFlux application, and it's honestly been quite a struggle. Although I have a background in distributed computing, the complications of WebFlux have overwhelmed me. Debugging production issues is especially tough, and often I find the documentation vague and assuming a high level of expertise. The project doesn't even actually require such a complex system, as it only needs to handle around 2,000 transactions per second, which makes me long for simpler approaches like KISS and horizontal scaling. Unfortunately, I don't have the authority to change this.
To complicate things, there are occasional mistakes from the library and SDK developers, which makes me hesitant about the stability and reliability of the components. It seems like the documentation is always leading with a "reactive first" approach. I was really hopeful that Java 21's support for virtual threads would alleviate some of these concerns, but instead, I ended up with new issues related to pinning. Maybe Java 25 will bring about the improvements we need?
5 Answers
I hear you! The next JDK version, JDK 24, might resolve some of those pinning problems you've been dealing with, especially with the 'synchronized' issue. I've recently upgraded our Spring Boot backend to Java 24 and switched on virtual threads, and the pinning issues I had with version 23 disappeared. So far, everything’s been smooth sailing in production!
Honestly, I've found that going reactive adds more complexity than it’s worth. Writing good reactive code requires a level of skill we often don’t have in our teams. Sometimes, simpler approaches end up being more effective.
I agree! Many projects don’t need the intricacies of reactive programming. A good mix of simpler structures usually does the trick.
It’s really ironic, isn’t it? We work with machines that handle calculations, but often the folks designing these systems overlook basic performance metrics. A lot of decisions around these technologies don’t seem to factor in the actual needs of the applications.
Exactly! Many business problems boil down to straightforward math, and yet it feels like we complicate things unnecessarily. It makes you wonder what’s driving those decisions.
As the architect of the Azure SDKs you’re using, I totally relate to your frustrations. We went the reactive route a while back, but in retrospect, it may not have been the best choice. We're currently exploring whether our next generation of libraries should stick to synchronous patterns, allowing users to implement their own async wrappers if needed. What do you think?
That sounds like a smart move! I believe having the option to choose between sync and async could make things way more straightforward for developers.
I’m pretty optimistic that virtual threads will help phase out the need for reactive programming in most cases, especially since many libraries and drivers are becoming more compatible with virtual threading. However, libraries still need to step up their support.
That would be a huge step forward! Migrating towards a more straightforward coding style could save a lot of headaches for developers.
That’s great to hear! It's encouraging to know that these updates can make such a significant difference.