Clear difference between spring web and spring web flux - spring-boot

I know this question has been asked a lot but i'm not able to find a CLEAR answer to my question.
The main difference i see between spring web and spring web flux is the use of Mono and Flux and ReactiveRepository. My question is : What is the difference ? (other than a syntax difference). I assume everything is different in the background but do we see these differences? Can we make something with flux that we cannot make with web mvc ?
I made a simple spring boot application using flux (playing with mono and flux) but only the syntax change, for me, i don't see any differences.
Thanks :)

Spring Reactive Gives the overview of WebFlux and Webflux is for asynchronous reactive programming & implements the Reactive Stream specification and webflux is for NIO uses cases.

Related

How to configure retries in Reactive Spring Integration application

I'd like to configure the retry policy as specified in the reactor documentation but I'm pretty confused by how it'll integrate the error channel concept of Spring Integration.
Can someone give a simple example of how the two integrate? And if not (which I'm fine with it), I'd like to know what is Reactive Spring Integration's alternative for this.
I've been also reading about Spring Integration's retry mechanisms and the page referenced reactive advice, but I didn't really understand how all of this sit together. To sum this confusion to a focused and clear question - how to configure retry policies in Reactive Spring Integration?

SSEemitter vs Flux in spring boot

I am having confusion between the SSEemitter and flux in spring Boot for sending one way asynchronous message to the client.
Want to know the use cases for both the terms with respect to Spring boot
One is using reactive/Flux and another is not. Here SSEemitter based implementation. You don't need reactive background. Reactive can take some time to understand if you haven't done it earlier.

Can I use a standalone WebClient without Webflux

I'm developing a reactive service and preparing to use the WebClient to exchange with HTTP APIs,but the service is not in a reactive web stack so how can I use it(WebClient) without depending on Webflux or is there any alternative reactive HTTP client?
Thanks in advance.
I am not sure if I get your question correct: You want to use an inherently reactive class without the reactive lib in which it is contained?
As you can see via the link you put in your question, the WebClient is part of spring-webflux and depends e.g. on reactor.core.publisher.Mono which resides in compile("io.projectreactor:reactor-core"). I can not imagine any scenario in which this WebClient would work or make any sense as you've asked "without depending on Webflux".
Other reactive HTTP clients are:
RxHttpClient
Java HTTP Client introduced in Java 11
May be you could elaborate a little bit more on your needs, why you won't rely on WebFlux or why you want to use a reactive client in a non-reactive stack.

Does Spring webflux supports socket.io or sockJs

Following spring webflux documentation
I couldnt but notice that every single example is based on pure websocket.
Does spring webflux supports such browser client libraries such as socket.io or sockjs?
The Spring Framework team is not considering this feature right now in WebFlux. Because of the back-pressure support in reactive streams, the team is considering protocols that would leverage that information.
For example, rsocket support would fit that space and much more. See SPR-16751

why we use jersey with spring? What are the benefits?

I want to know that why we use jersey with spring and what are the benefits of using it.
I have searched on google but not getting proper answer so i am asking this question here.Sorry because i know my question is old but i am very confused now.
Please suggest me the example of jersey with spring and hibernate.
Thanx in advance.
I use Jersey2 with Spring in one of my projects and in the other Spring MVC4. The advantage of Jersey is its simplicity. If you are creating only RESTful Web services - use Jersey, if you have to generate also some web pages for users, consider to use Spring MVC.
Additionally, I develop my applications on Google Cloud, so the warm up time is very important (if there is a traffic spike, many instances have to wake up in the background to be ready for incoming requests) - according to my tests Jersey is a bit faster than MVC.
Here you have an example of complete configuration:
Integrating Jersey 2 and Spring with Java Based Configuration

Resources