As you all probably know, Axon Framework works easy with Spring Boot. Most of the components have auto configuration, and even most extension have auto configuration modules which via starters make them easy to use.
But this is only available for Spring Boot. If you are using Micronaut or Quarkus you need to so some configuration yourself. This can be quite a lot, as can be seen in this Quarkus example. But I wonder for how useful it would be to add support for either Microprofile or Micronaut. Now Spring Boot 3 made native compilation easier, I’m not sure there will be many users of either Quarkus or Micronaut in the near future.
Something else we don’t really support yet is Kotlin coroutines. While Kotlin itself can be used with Spring Boot, subscriptions is something else. It is something we can improve through, and I did experiment with a coroutine event processor. I’m sure we could do more, but also in this case, I wonder how much interest there is.
This thread is mostly for discussion, so no promises. I do like to hear any reason for improving support for other runtimes.
I think that Spring comes with a lot of things - first and foremost there is unwanted complexity. First, you set up your project, then you spend a week configuring Spring and Axon.
It appears to me that Micronaut takes a much more minimalistic approach. Have you considered conducting a survey on potential usage yet?
I’m new to Axon and starting to evaluate it at it as a candidate for a new product/system. I’d personally be very interested in improved Kotlin support (e.g. coroutines), and even more interested in improving ease of use/DevX without Spring/Spring Boot. We aren’t a Spring shop, and while it’s not out of consideration to use it, it would be reassuring to know that we don’t need Spring to be a ‘first class citizen’ when using Axon - especially when we have legacy systems that we may want to integrate into the Axon platform down the road in a first-class manner.
But again, I’m new to the platform and don’t really know much about how tightly Axon and Spring are tied together, and what challenges are introduced when using something different. Just thought I’d add a minority voice to the topic to show some interest.
All voices are welcome. The main problem is that most examples are Spring Boot, and almost all applications we build ourselves use Spring Boot. Mostly because of the auto configuration part, which means you need to write a lot less code yourself.
We also have Synapse now, which does make it very simple to just publish an event, or just send a command or query.
I would encourage anyone reading this to also make their voice heard. We only have limited resources, and it would be a big help to spend them wisely.
The good thing about AxonFramework is that it doesn’t depend on Spring Boot itself (besides dev dependencies and testing). And this leads to great flexibility when it comes to integrate it with other Frameworks, even if this comes with some effort.
In my particular case I knew that the company I worked for back then wouldn’t switch to Spring Boot. We had great knowledge in Jakarta EE (former Java EE) and strong standardization focus. I knew that if I would ever want to do anything with AxonFramework, I would need to find a way to get it to work with Jakarta EE or Microprofile. At the same time Quarkus came up and I had a lot of fun playing around with Quarkus and AxonFramework in in my free time and contributing to both of them.
I guess that bigger companies e.g. in finance use Jakarta EE and therefore Quarkus is the ideal next step. Quarkus also comes with a huge ecosystem that makes it easy to integrate it with all kinds of technologies and embraces Cloud first.
The native build was the most fascinating thing for me when I heard from it the first time. In practice, I’m not so sure if it is really necessary for most projects. Sure, crazy fast startup times and a small footprint are great to have for serverless functions in the Cloud. Besides that, native mode doesn’t automatically mean that the application runs faster.
So it all comes down to how big the Jakarta EE / Microprofile community using Quarkus or Helidon actually is and how much potential there is to adopt AxonFramework. In banking I see great value for it because reporting is a big topic there and specialized projections would make that much faster and transparent in comparison to analytics on top of Data Warehouses. But that’s just my opinion.
When it’s done. We still have internal discussions about the exact scope. And we only recently started actual coding. So not soon. It would be great if we had something like a beta at the next conference, bit no promises.
.