|Helidon Microservices Framework Version 4 Reaches General Availability|
|Written by Nikos Vaggalis|
|Thursday, 16 November 2023|
Helidon, the open source microservices framework by Oracle, has been updated to version 4, just a month after the release of Java 21. With this release Helidon becomes the world’s first virtual threads-based microservices framework.
But a bit of history first.
Helidon sprang up back in 2018 from the lack of agility of Java/Jakarta EE in building microservices. Sure you could do that, but not in the most efficient way. Thus at Oracle they thought of a framework designed from the ground up for building microservices would be more efficient. In order to stay close to the Java EE spirit, Helidon was made to implement the Microprofile standard, widely used in Java EE environments.
So far so good, but the ground breaking feature that was added to Helidon's 4. 0. 0-ALPHA1 release, was the technology preview of a new side project, Helidon Nima, which was introducing virtual thread support to the framework. The reason of introducing virtual thread support stems from the fact that:
Prior to Helidon Nima, developers would have a choice to use Helidon MP and write JAX-RS applications, or if they needed a higher level of performance and throughput they could use Helidon SE and write reactive based services. However, the reactive based services are more complex to write, maintain, and debug.
Now v4 makes virtual thread support official and available for production workloads, as such switching completely from the Netty server implementation which was supported in version 3x, to Nima. With this move , Helidon can now fully harness the capabilities of Java 21’s virtual threads.
The official blog release states :
Since each request now operates within its own dedicated virtual thread, it can freely execute blocking operations, such as interfacing with a database or another service, in a straightforward synchronous manner without the risk of obstructing a platform thread and depriving other requests of resources.
This eliminates the necessity for complex asynchronous code to create a low-latency, extremely concurrent service.
Does it mean that it will render Reactivity a thing of the past? It's a topic I had examined in Hibernate goes Reactive - What Does That Mean?
the R2DBC spec provides a rough outline to communicate with a relational DB in a way that doesn’t block disk I/O. The spec itself is really just a guideline, and the actual implementation is left up to you but it can also be used in combination with CompletableFutures.
The gist being the DB wire protocol implementation can be used in a more efficient way, eliminating threads, thereby decreasing memory usage and possibly Increasing throughout. Of course, it all really depends on the use case.
So virtual threads as far as the non blocking IO aspect of Reactivity goes, surely will replace it and make a difference too as the code to write will be much simpler. Saying that, Reactivity however means much more than that. It means also the caller/subscriber controlling the volume of the data returned by the publisher/database, aka backpressure, streaming results, and of course the advantage of Reactive programming versus the imperative model. Therefore Reactive frameworks still hold value.
But that's not all. The new version regarding Helidon MP got upgraded to MicroProfile 6. 0. And due to the change to non blocking APIs and virtual thread support, old Helidon 3 SE code needs to be tweaked in order to work with them. For that reason, there is an official upgrade guide released.
To sum it up, is the support of virtual threads going to grant Helidon the edge over the rest of the Java Microservices frameworks like Micronaut and Quarkus, and as such a greater adoption? Time will tell, soon enough.
or email your comment to: email@example.com
|Last Updated ( Thursday, 16 November 2023 )|