Helidon Nima - The Future of Web Services

Author:

Eric Kolotyluk

Created at:

Jan 2023

Updated at:

Jan 2023

If you are a back-end developer, or work with back-end developers, I strongly recommend watching this presentation: Helidon Nima - Loom based microservices framework

At Forgerock, we use Helidon SE and ME for some of our microservices, where SE is like the engine, and ME is the whole car, including the engine. Later this year (2023), Helidon version 4.0 should be released with Helidon Níma, where eventually Helidon ME will use Níma instead of SE.

Helidon SE

is based on Reactive Programming techniques (see also The Reactive Manifesto), in particular the Java Flow API introduced in Java 9.

Helidon Níma

is based on conventional imperative blocking code, but using Java Loom Virtual Threads. Our friends at Okta wrote a great description of Loom in What the Heck Is Project Loom for Java? But sometimes it’s best to hear it from the masterminds themselves, The Age of Virtual Threads by Ron Pressler And Alan Bateman.

Comparison

Helidon SE	Helidon Níma
Based on less intuitive, Non-Blocking, Reactive Programming, typically Functional Programming style	Based on more intuitive, conventional Blocking Programming, may be Imperative or Functional style
Fast, efficient, low overhead, high throughput	Fast, efficient, low overhead, high throughput
Complex, harder to write, harder to read, harder to debug, harder to test	Simpler, easier to write, easier to read, can use conventional debugging practices, easier to test
Helidon ME has excellent throughput	Helidon ME has twice the throughput
Helidon 3.0 requires Java 17	Helidon 4.0 requires Java 19, but the target should be Java 21 for its Long Term Support

Helidon SE

Helidon Níma

Based on less intuitive, Non-Blocking, Reactive Programming, typically Functional Programming style

Based on more intuitive, conventional Blocking Programming, may be Imperative or Functional style

Fast, efficient, low overhead, high throughput

Complex, harder to write, harder to read, harder to debug, harder to test

Simpler, easier to write, easier to read, can use conventional debugging practices, easier to test

Helidon ME has excellent throughput

Helidon ME has twice the throughput

Helidon 3.0 requires Java 17

Helidon 4.0 requires Java 19, but the target should be Java 21 for its Long Term Support

Looking Forward

Because both Helidon and Java are developed at Oracle, the Loom and Níma teams have been working together to test this new technology together.
While Níma may not be using Structured Concurrency yet, it almost certainly will by Java 21. In the meantime, we can use Structured Concurrency with Níma today.
- Structured Concurrency should be much preferred over Executors
- Also, Virtual Threads should never be used with Thread Pools, where Structured Concurrency uses Virtual Threads by default
Ultimately, Helidon Níma will deliver more performant microservices, that are easier to develop, debug, and test… basically an overall better Developer Experience, that improves ROI by decreasing TCO.
- While the Developer Experience is better, there are some old habits than should be unlearned
  - e.g. Virtual Threads should never be used with Thread Pools
  - For more details, see The Age of Virtual Threads by Ron Pressler And Alan Bateman
Helidon applications can use JLink for smaller runtime and faster startup, and can use GraalVM for the fastest startup.
- GraalVM Polyglot features enable building efficient, small, performant multi-language web applications
Friends don’t let friends use Spring (did he really say that? ). Actually, using GraalVM, even Spring applications can be smaller with faster startup.