Evaluating Spring Boot, Quarkus, or Micronaut and why for Stargate v2
Author: Ivan Senic
In this article, you’ll learn the decision-making process behind why Stargate for Apache Cassandra chose Quarkus over Spring Boot and Micronaut as their chosen Java framework.
Stargate has been around since 2020. In that time, it has helped companies like Netflix, Yelp, Netlify, PrepLadder, SHIELD, and more, who take advantage of the power of the open source NoSQL database, Apache Cassandra®, to make their data more accessible through APIs.
Stargate turns Apache Cassandra into a cloud data service. You can connect applications, services, and functions to Cassandra over HTTP APIs and Drivers, injecting limitless scale and speed for the data plane. In addition to supporting Cassandra’s traditional CQL interface, you can go driverless with Stargate v2’s high-performance gRPC implementation! It’s just as fast as native database drivers, and with so much of the networking configuration done by gRPC automatically, it is much easier to use (and learn).
With Stargate coming to a stage of maturity, it’s time to bring significant change to the architecture, which will address opportunities for improvement recognized in the original architecture.
The need for improvements
Frameworks in the tech world grow at extraordinary speed. However, if you aren’t constantly aware of the latest and greatest, you could be at a disadvantage by not having the modern frameworks that offer improvements straight out of the box.
The main reason behind Stargate v2 development is to help modernize the tech stack across a number of fronts in order to reap the benefits for Stargate users.
Moving away from Dropwizard
Stargate v1 used Dropwizard as its framework for exposing HTTP endpoints, but the project is no longer well maintained and more modern frameworks are now available with superior features.
Stargate v2 was also a chance to factor out the APIs and make their services independent. With Stargate being open source, these changes will help people internally and externally use the APIs without having in-depth knowledge of Cassandra.
Factoring out the APIs also means that changes can be released and deployed independently rather than waiting for them to be bundled together.
Framework evaluation requirements
The framework had to make sure it hit some marks.
- The learning curve had to be forgiving. The last thing was to introduce a new framework, which no one wanted to adopt and be stuck in some weird limbo. The framework had to be something the whole team could get behind and pick up effortlessly.
- The framework needed to have many features out of the box. This way, progress can be made immediately without spending additional developer resources. In particular, the framework had to have excellent gRPC support, as this was something that Stargate relies heavily on for communicating.
- Performance across the board. From startup time, to runtime performance must be considered to help the developer experience. Reactive support was also important for this same reason.
Three Java frameworks were the front runners: Spring Boot, Micronaut, and Quarkus. To help choose which framework was ideal, a table was created listing all of the features for each framework and scoring them appropriately to how they impacted Stargate. We compared each framework in terms of required JDK, dependency management, configuration, Docker image building, configuration, reactive programming APIs, observability, security, and community involvement.
Spring Boot, a popular choice for application development, fairly quickly revealed itself not to be an option due to the:
- The lack of official support for gRPC.
- The fact that native image building was in an experimental mode still.
- And Spring Boot was strong in retrieving data, but that wasn’t a requirement for Stargate.
So it was a one-on-one fight between Micronaut and Quarkus.
And who was the winner?
It was a close decision, as they provide many similar features. Ultimately, the deciding factors were:
- gRPC support — The losing framework didn’t support all gRPC features.
- JDK 17 — At the time of the decision-making, they didn’t fully support Java 17, which is important for Java language features like Z Garbage collection and GraalVM native image compilation.
- Integration testing — We needed a framework that could handle wiring-in custom environments and dependencies like a Cassandra cluster.
- Observability support — A complete out-of-the-box support for metrics and tracing, for both HTTP and gRPC traffic.
- Community — A vibrant community is essential to the ongoing health of our selected framework.
Based on all these factors, the winning framework was Quarkus.
Before fully adopting Quarkus, we performed a trial to get a hands-on feel, and we discovered that it was the right framework for Stargate. Quarkus has excellent documentation full of detailed guides for all extensions, letting you clearly understand how to achieve your goal and clearly shows configuration properties.
Another great thing about Quarkus is the compatibility between extensions. You can activate different extensions that work together, creating a unified experience. You don’t need to worry about issues when pairing extensions together.
A nice feature of Quarkus is Dev mode. Dev mode allows you to change your application source, resources, or configurations, which are then automatically reflected in your running application. This way, you can get quick feedback to see how your changes may have impacted your application.
You can see the results of our efforts in the new Stargate v2 release. We’ve implemented Stargate’s REST, GraphQL, and Document APIs as Quarkus-based microservices that can be deployed and scaled independently from the rest of the Stargate architecture.