Spring in Action Question/Spring Reactive vs non-reactive

[Vuk Djapic]

Recently I tried Spring Gateway for our microservice setup, and as part of it had to learn Spring reactive programming.
Struggled some time in attempt to configure the Gateway the way I wanted, finally gave up and continued with Zuul 1. But it's not just that I didn't succeed to configure it - honestly, didn't like Spring's reactive style of programming. But with Spring Gateway it is the only option, reactive types must be used.

So the question is - where the Spring reactive way of programming is going? Why it is so eagerly promoted? Will it remain just an option or mandatory for some of the Spring projects, like it is for the Gateway?
To me it seems that Spring's team is pushing it, reminds me of the similar kind of promotion between Java and JavaFX.

[Craig Walls]

You are correct in saying that Spring Cloud Gateway is itself developed in a reactive fashion, based on Reactor. And if you are going to customize Gateway in any way, you'll need to get on board with that model. The reason Gateway made that decision is in order to support things like WebSocket, RSocket, and others that really benefit from a reactive streams model. But if you're using Gateway as the front for a service, that service doesn't require a reactive model. You can use good ol' imperative Spring MVC to create the service and reactive Gateway in front. No problems at all. I do it all the time.

AFAIK, no other piece of the Spring landscape requires reactive in any way (aside from the obvious, like Spring WebFlux). But the Spring folks do talk up reactive a lot because there are some obvious benefits from taking a reactive approach (in short, doing more with fewer threads) and because a lot of projects will benefit from it. But just because it's the hot topic of the day doesn't mean that we're requiring you to apply it in your projects. In fact, in my book, I don't even touch on the reactive topics until halfway through the book because (1) I don't think it's necessary for all projects (2) there are some non-reactive essentials to get out of the way first, and (3) I definitely want to communicate that it's optional.

Again, Gateway itself is reactive so that it can support a broad range of services that it fronts, but those services do not have to be developed in a reactive model themselves. And, unless I'm forgetting something, no other bit of Spring requires reactive in any way. I would encourage you to get to know Spring's reactive programming stuff...but you aren't required to use it.

[Vuk Djapic]

Hi Craig,

Thanks a lot for the answer, really clarifies it.
I wanted to use the Gateway also to resolve security in a multitenant environment, and some helpful MVC context beans just aren't there any more. Ended with Monos and Fluxes everywhere in some complicated unreadable lambdas.
But understand the benefits of it, and probably needs some practice to get used to the programming model. Will certainly give it a try again, looking forward to read those chapters in your book!

[Rob Spoor]

Vuk Djapic wrote:in some complicated unreadable lambdas.

That's easily remedied - extract the lambda code into a separate method. I do that all the time. Whenever a lambda becomes unreadable (and when using them for stream filter or map operations, that's after one line already), I replace it by either a method reference, or a single method call (if the method needs more arguments than just the current element in the stream).

[Claude Moore]

Rob Spoor wrote:

Vuk Djapic wrote:in some complicated unreadable lambdas.

That's easily remedied - extract the lambda code into a separate method. I do that all the time. Whenever a lambda becomes unreadable (and when using them for stream filter or map operations, that's after one line already), I replace it by either a method reference, or a single method call (if the method needs more arguments than just the current element in the stream).

That's a good advice. Many times I had the feeling that one is forced to use complicated and hardly readable lambdas just to show that he or she can effectively manage lambdas.
Lambdas are meant to simplify programmers' lives and make code more compact and clear, and IMHO this point should never be missed.