Select framework for Java-based API Service implementations #1526
Replies: 6 comments 13 replies
-
|
I would like to contribute to this discussion and present my personal opinions on what should be considered when selecting a new framework. Please consider the table below as the non-final, as I can not cover everything and might be adding things that pop-up in addition. Not everything is mandatory, and some items weight more than others of course. I tried to fill in the data about support in frameworks that I have from my experience and from reading the official documentation. Pending analysis
RecapMicronautSeems that biggest pros of the Micronaut is in the support for the gRPC, not only with the wrappers, but with tracing and testing as well. The native image support with the AOT compilation should provide very good if not the best startup times and memory consumption. It feels that security support is limited, but then again it's quite questionable if we would be able to use any support here at all. Documentation feels personally to me often too short and limited, but is definitely good for general usage and covers basic use-cases. SpringBootSpringBoot should have best documentation, examples and community around. I am pretty sure the extensive security features it offers would win over other frameworks, but it's questionable how much of that we can use. It lacks official support for the gRPC and since our communication protocol will be gRPC this seems like a problem here. Reading some of the framework comparisons pointed that Spring has worst startup times and highest memory consumption. It's expected that the developers in general have the most experience with SpringBoot, due to it's huge adoption. It's also more likely that Spring would have support for any features we might need in the future and that were not recognized in the list above. QuarkusQuarkus has a complete support for gRPC, including the full observability. Seems that all major features are available, except the auto-configuration based on the class path. I feel that the biggest con for Quarkus is that it's based on the Multiny reactive framework. The other two frameworks are taking Project Reactor as the main framework and it seems that Reactor is becoming the de-facto standard with a lot of great features. It's unknown how experienced are Stargate contributors with the Multiny framework and what is learning curve gonna be. It's unclear what's the current state with the Java 17 support and when it will be fully supported. It's also unclear how it compares against other frameworks wrt the native image building. Documentation / Further ReadingMicronaut(Docs)
Quarkus |
Beta Was this translation helpful? Give feedback.
-
|
I see that all 3 options support Open API 3 integration (Swagger), but I would like to add Swagger annotations as a selection criteria as well, if possible. We (Docs) would like to add extensive swagger annotations to the source code, so that we can generate proper OS yaml files directly from the source code. Currently, we have to heavily edit the yaml file that is generated by swagger. |
Beta Was this translation helpful? Give feedback.
-
|
Alternatively, the source code could use an oas.yaml file directly. I believe cloud-ondemand does that: |
Beta Was this translation helpful? Give feedback.
-
|
@polandll Wait are those annotations available in the Open API integrations? From my experience those are like: At least from my previous SpringBoot projects those are the ones that you get with: We can further check this, but I guess every framework supports this.. For example, Micronaut points to the same, as well as Quarkus apparently. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you @ivansenic for the comprehensive list of criteria. That should help in figuring out what choice to make evaluating the best choice as the future framework. All the notes make sense and align with what I have heard of frameworks (my experience is limited to some use of Spring Boot; I have only read about the other 2 newer ones). One thing that might be worth noting is that the current framework (DropWizard/Jersey/JAX-RS) does not have in-built support for gRPC or Reactive processing (I think), but Stargate uses both. So in a way explicit framework support is not mandatory for either, I suspect, although can be a big plus. |
Beta Was this translation helpful? Give feedback.
-
|
@tatu-at-datastax I would actually argue that explicit framework support is somehow mandatory.. Or at least expected.. The first reason is the dependency management. If you don't have to bring a 3rd party library to support something, that you can really on the framework releases to cover needed updates for that specific feature(s). Meaning you don't have to maintain compatibility of the 3rd party solution and update it yourself. Furthermore, integrated solution exposed by a framework will also be way more tested as it's an official solution, then if you bring extra library. Second thing is the free lunch you get wrt other concerns. Take gRPC for example, bring your own 3rd party solution means you need now to integrate also metrics and tracing for that library into the existing concepts of the framework.. That's extra work that you need to invest in, instead of relying on again well tested integrated options that framework expose. |
Beta Was this translation helpful? Give feedback.
-
|
All I am saying is that we have managed to get things working without in-built support. Not that we should ignore integration opportunities, or that there weren't any benefits. |
Beta Was this translation helpful? Give feedback.
-
|
Should we consider JAX-RS (Annotation) support as well? Spring Boot has it, trying to figure out if Micronaut has it explicitly (or requires use of annotation mapper) |
Beta Was this translation helpful? Give feedback.
-
|
Correct: support use of JAX-RS annotations (instead of framework native ones). I don't think we rely too heavily on other JAX-RS functionality. |
Beta Was this translation helpful? Give feedback.
-
|
But why would this be important? |
Beta Was this translation helpful? Give feedback.
-
|
Our current API is defined using those annotations, and they are sort of standard in Java world. So it seems beneficial to be able to use those. Not a blocker but if using framework-specific annotations there is more work to convert to the framework (and if we didn't like it, away). Micronaut has some level of support for translating JAX-RS annotations, f.ex: |
Beta Was this translation helpful? Give feedback.
-
|
I see what s your point, you don't want to remap the code to the framework-specific annotations.. And I get you.. But I guess this is not such a hard work, and some changes will be needed for sure.. But I can add it to the list of the features 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Sounds good to me! I definitely would not consider this a must-have. |
Beta Was this translation helpful? Give feedback.
-
|
One suggestion: since most of team members are probably not very familiar with Quarkus or Micronaut, we could add links to documents/articles that give good overview of their usage. This could help everyone get familiar with kinds of changes, improvements, beyond just listing functionality offered. At least for me watching presentations about Micronaut has been helpful in realizing how big the changes are, wrt reducing work needed (but also changing to use more and more indirection via annotations, naming conventions). Fine to add Spring Boot ones too of course. |
Beta Was this translation helpful? Give feedback.
-
|
Sure why not... Here are some of the interesting docs from my point of view: @olim7t @tomekl007 Totally forgot to add the GraphQL to the table, please check the guides above and see if this brings any benefit to you. |
Beta Was this translation helpful? Give feedback.
-
|
One section of the table above that's empty at the moment is observability -- I don't have any experience with Micronaut or Qurkus on that front but I've found what Boot provides through actuator and the potential to easily bolt in the spring-boot-admin application really quite complete. It should provide what's necessary for K8s probes out of the box as well: https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.endpoints.kubernetes-probes |
Beta Was this translation helpful? Give feedback.
-
|
Observability is the section with 4 items below (metrics, tracing, etc).. I think I made confusion with bold text, will fix it.. Bold text -> section header.. |
Beta Was this translation helpful? Give feedback.
-
|
Also thanks for putting up this convo @jeffreyscarpenter @tatu-at-datastax @ivansenic I think this type of discussion can be really useful for a lot of different folks who are facing decisions like this in many different projects, not just ours here. |
Beta Was this translation helpful? Give feedback.
-
In the first milestone of Stargate v2, we separated out the REST API Service from the Stargate coordinator node as a separately deployable microservice. In the first stage of this refactoring, the service was not changed from its current configuration as a Dropwizard-based service running against Java 8.
One of the next steps in the maturation of this REST API Service is to migrate it to a more modern Java framework, which should go along with upgrading our Java version. Various frameworks have been proposed, including Spring Boot, Micronaut and Quarkus.
This discussion is intended to kick off the effort to select a new framework to be used for the REST API service and other Java-based API Services.
Here are a few proposed requirements or ways in which we might compare frameworks:
Are there other requirements or frameworks we should consider?
Beta Was this translation helpful? Give feedback.
All reactions