As explained in the Spring Boot reference documentation, Spring Boot will auto-configure a Spring MVC application if both MVC and WebFlux are available. There are several reasons for this:
- Spring MVC can't run on Netty
- both infrastructure will compete for the same job (for example, serving static resources, the mappings, etc)
- mixing both runtime models within the same container is not a good idea and is likely to perform badly or just not work at all
Depending on the goal you're trying to achieve, there might be several ways to work on this.
If you'd like to use WebClient
to optimize for multiple, concurrent remote HTTP calls and use Reactor operators, you can keep using Spring MVC annotated controllers and return reactive types as return values (more on this in this Spring Boot talk).
If you'd like to work on pure scalability and latency (so not necessarily raw throughput), then you could start using spring-boot-starter-webflux
and work from there. Note that using blocking APIs (like blocking database calls) is forbidden, and wrapping those with Flux
or Mono
and scheduling that work on separate thread pools will work against you on the performance side.
Finally, if you'd like to use the functional approach provided by Spring WebFlux, then it won't necessarily perform better. It really depends on your use case and how you implement it.