The mainstream opinion about using a reactive non-blocking backend is that it increases performance for large numbers of clients but sacrifices maintainability due to increased complexity.
I am in a situation, in which the performance issue is not that important, it is rather low-scale with probably no more than a dozen simultanous clients- it could well be handled with plain old blocking I/O from this perspective.
However, we found that providing a SSE-based API based on Spring Webflux would simplify the communication between backend and the frontend which uses Angular and rx/js. On the client side you could just subscribe to the reactive EventSource, instead of handling polling etc.
I am aware that SSE can be done with Spring MVC as well, but manually providing SSE messages seems much more effort than just creating a Flux and exposing it to the controllers. Especially, considering that the team uses the reactive programming model in the frontend anyway.
So the goal would not be to go full reactive in the backend but to provide an API that is easy to consume and take advantage of the framework that provides SSE support based on project reactor almost out-of-the-box.
The question is whether I am missing potential drawbacks of using Webflux to implement an SSE-based API in this scenario.
I am curious because my reason to consider this approach does not align with common answers e.g. on this site which focus on performance aspects vs in increase of complexity. The conclusion seems to be only do reactive in the 10% of cases with very high requirements for parallelism for which thread-based models do not suffice.
Do the performance issues still apply if the use of reactive Streams is limited e.g. to the use of simple factories in the presentation layer?