In Spring Webflux, what's the difference between ResponseEntity<Mono> versus Mono<ResponseEntity> as a return type of a rest controller?
When is the most appropriate to what?
Following up on this question, let's say I need to return a list, or let's say several elements of Foo, there are many examples of returning Flux.
Would it make sense to return ResponseEntity<Flux> or Flux<ResponseEntity>?
When I'm looking for this question, I found the same question posted here: https://github.com/spring-projects/spring-framework/issues/22614, but no answer, I searched spring docs, but find no info.
Thanks for the help.
Here are the various options you can make with a ResponseEntity return value:
ResponseEntity<Mono<T>> or ResponseEntity<Flux<T>> -- this makes the response status and headers known immediately while the body is provided asynchronously at a later point. Whether the body is Mono or Flux depends on how many values the response has.
Mono<ResponseEntity<T>> -- this provides all three -- response status, headers, and body, asynchronously at a later point. IT allows the response status and headers to vary depending on the outcome of asynchronous request handling.
Mono<ResponseEntity<Mono<T>>> or Mono<ResponseEntity<Flux<T>>> are also possible but less common. They provide the response status and headers asynchronously first and then the response body, also asynchronously at a second point later.
https://docs.spring.io/spring-framework/docs/current/reference/html/web-reactive.html#webflux-ann-responseentity
WebFlux supports using a single value reactive type to produce the
ResponseEntity asynchronously, and/or single and multi-value reactive
types for the body.
So the return type on an annotated controller would actually be a Reactive Publisher like Flux or Mono that emits an object representing the data to return.
Example
Flux<AccountDto>
Or also:
Flux<ResponseEntity<AccountDto>>
I think you can even just set a raw DTO type as the return type and Webflux will automagically wrap it in a publisher for you.
Valid Return Types
https://docs.spring.io/spring-framework/docs/current/reference/html/web-reactive.html#webflux-ann-return-types
Example: https://github.com/oktadeveloper/okta-spring-webflux-react-example/blob/react-app/reactive-web/src/main/java/com/example/demo/ProfileRestController.java
Non-blocking Reactive Paradigm
When doing Reactive Programming you want to every layer to communicate via Flux/Mono. So you would get back a Flux from your ReactiveRepository and the service layer would also return a Flux to the Controller. Basically, in reactive programming everything is a Flux/Mono.
Internals
While SpringMVC and Spring Webflux annotated controllers look similar, they are vastly different internally. For instance, Webflux uses Jetty while SpringMVC uses Tomcat by default. Internally, Webflux is more like a non-blocking event-loop architecture while SpringMVC traditionally leverages a threadpool with 1 thread per request blocking for I/O.
Check out this article for more details on Spring WebFlux
Related
At what point does the spring webflux do the subscription? Everywhere I have read that there must be a subscription otherwise no change happens. In my short time with Spring Webflux, I have never seen a subscribe() neither in the controller or services.
My doubt is also when using flatMap(), map(),... etc.. at what point does the subscription take place?
What I have read does not really resolve my doubts.
public Flux method(){
....
myFlux.flatMap(data -> {
....
}).flatMap(e -> { .... });
}
I know this is an asynchronous issue, but each flatMap runs at the same time?...and so sometimes some data I have noticed is null.
It's the framework (spring-webflux) that subscribes to the returned Mono or Flux. For example if you use Netty (that's the default), then subscription happens here based on my debugging:
https://github.com/reactor/reactor-netty/blob/db27625064fc78f8374c1ef0af3160ec3ae979f4/reactor-netty-http/src/main/java/reactor/netty/http/server/HttpServer.java#L962
Also, this article might be of help to understand what happens when:
https://spring.io/blog/2019/03/06/flight-of-the-flux-1-assembly-vs-subscription
You need to call a .subscribe() or block() function after your flatmap. Here's an example.
Assuming that myFlux is of type Flux, the following will execute the subscription based on the example above
myFlux.subscribe(System.out::println);
Here's an explanation on a separate StackOverflow thread.
But in your method function, you are returning a Flux object - so it's up to the consumer of the method() function how it wants to subscribe to the Flux. You shouldn't be trying to subscribe to the Flux from within
The answer is: it depends.
For example, if this is a Spring Controller method, then it is the framework itself that subscribes to the Mono or Flux.
If it is a method that is triggered from time to time by a Scheduler, then you must explicitly subscribe to the Mono or Flux, otherwise, no processing will take place.
This means that if your application only exposes a REST API and no processing need to be triggered in any other way, then it is very likely that you will never need to explicitly subscribe to a Mono or Flux because Spring will take care of that by you.
Looking to make a service call based on a header value.
I can see two options:
1) Do it from the controller which is mainly used for a different service.
2) Add a filter which will do this by reading the request context.
Want to know what's the best way to handle this in a Spring application.
I guess it depends on your requirements.
Controller:
If you have to make service calls for preparing the response of a specific controller. For example, you have a controller say:
/employee
fand or preparing the response of this endpoint you need to call say staff service.
In this case, it's better to handle such calls in controllers.
Filter:
If you want to intercept each request and perform some operation on the request before sending it to the controller or before sending the response to the client.
A use case here can be checking the roles of the user by intercepting all requests.
As we know by using the filter, we can perform two operations at two instances −
Before sending the request to the controller
Before sending a response to the client.
In this case, OncePerRequestFilter is quite useful from the spring web module.
Quoting the documentation :
Filter base class that aims to guarantee a single execution per request dispatch, on any servlet container.
How can i call 3 different GET rest apis asynchronously in Spring Boot? Currently its taking alot of time to execute this apis sequentially. Let me know how to do this asynchronously?
You can use async-http-client as given in the following url : https://www.baeldung.com/async-http-client
2.You can use AsyncRestTemplate. In AsyncRestTemplate object you need to send the following three parameters.
* endpoint uri,
* request entity with headers,
*and response object.
Catch all those in to a ListenableFuture object where implement the override methods of callback in the case of failure and success.
For both of these approach, you have to create request objects and call the services. And the call backmethod will capture the result in the response objects. You can merge responses together and then do your business.
You can use #EnableAsync annotation at the configuration level to enable async processing and #Async at the method level which needs to be invoked asynchronously.
For further details please refer to the below link
https://www.baeldung.com/spring-async
Have written a microservice(Using webFlux) which in turn calls three other microservices(Not using webflux). New microservice call the other three using flatmap. and controller is returning Mono . Is this correct Design. Do I need to pushlishOn?
Mono<String> result =service1.api(input)
.flatmap(innput-> service2.api).flatmap(input-> service3.api);
And Controller is also Returning Mono . Is the design correct. Will it be working in non-blocking way?
The publishOn method does not change code either into non-blocking or blocking code. All it does is force downstream operators to run in a different thread. However, if the service calls made within those threads are blocking, then you'll just be blocking another thread if you use publishOn.
So, to answer "Will it be working in non-blocking way", it actually depends on how you implemented service1.api(), service2.api() and service3.api(). If they synchronously fetch your data, then it will still be blocking, no matter what you do.
However, if you use the new WebClient API for example to reactively fetch your data from your three microservices properly, then yes, it should be non-blocking.
In Spring 5 I just know Spring WebFlux Handler method handles the request and returns Mono or Flux as response.
#Component
public class HelloWorldHandler {
public Mono<ServerResponse> helloWorld(ServerRequest request) {
return ServerResponse.ok().contentType(MediaType.TEXT_PLAIN).body(BodyInserters.fromObject("Hello World"));
}
}
But I have no idea what means Mono and Flux and how it works with the WebFlux Handler.
Can any one simply explain
1.What means Mono and Flux.
2.How it works with the WebFlux Handler.
Thanks in advance.
Webflux is all about reactive programming, which in summary means that business logic is only executed as soon as the data to process it is available (reactive).
This means you no longer can return simple POJO's, but you have to return something else, something that can provide the result when it's available. Within the reactive streams initiative, this is called a Publisher. A Publisher has a subcribe() method that will allow the consumer to get the POJO when it's available.
A Publisher (for example Publisher<Foo>) can return zero or multiple, possibly infinite, results. To make it more clear how many results you can expect, Project Reactor (the reactive streams implementation of Pivotal) introduced two implementations of Publisher:
A Mono, which will complete after emitting a single result.
A Flux, which will emit zero or multiple, possibly infinite, results and then completes.
So, basically you can see Mono<Foo> as the reactive counterpart of returning Foo and Flux<Foo> as the reactive counterpart of Collection<Foo>.
For example:
Flux
.just(1, 2, 3, 4)
.map(nr -> nr * 2)
.subscribe(System.out::println);
Even though the numbers are already available (you can see them), you should realize that since it's a Flux, they're emitted one by one. In other cases, the numbers might come from an external API and in that case they won't be immediately available.
The next phase (the map operator), will multiply the number as soon as it retrieves one, this means that it also does this mapping one by one and then emit the new value.
Eventually, there's a subscriber (there should always be one, but it could be the Spring framework itself that's subscribing), and in this case it will print each value it obtains and print it to the console, also, one by one.
You should also realize that there's no particular order when processing these items. It could be that the first number has already been printed on the console, while the third item is hasn't been multiplied by two yet.
So, in your case, you have a Mono<ServerResponse>, which means that as soon as the ServerResponse is available, the WebFlux framework can utilize it. Since there is only one ServerResponse expected, it's a Mono and not a Flux.