Gain insights into building Reactive Web Applications with Spring Boot 2 and Spring WebFlux, from database integration to front-end. Explore Reactive vs MVC, performance, and deployment with Docker.   


Full Reactive Stack with Spring Boot 2 and Spring WebFlux.png

tarball.tar.gz

initialzr

spring-mongo-only

Lesson-playing-with-reactive-endpoints

angular-app-with spring-mongo

angular-app-with spring-mongo-copy

spring-mongo-only-copy

initialzr-copy

This course is your guide to using Spring Boot 2 and Spring WebFlux to create Reactive Web Applications. 

You will learn how to build a full-reactive system from the database (MongoDB reactive) to the front-end (Angular), using a Reactive programming strategy leveraged by Spring WebFlux, with the simplicity offered by Spring Boot 2. 

Beyond that though, you will be able to compare the Spring WebFlux with the standard MVC approach as well, covering the main aspects such as simplicity, performance, user experience, and more.

The last part of the course ties it all up by teaching you to run the application using Docker compose. By the end of this course, you will have a great new skill for your resume and you’ll be able to build your own projects using the full Reactive stack.

Full Reactive Stack: Spring Boot 2 & Spring WebFlux

There are no noticeable differences between the blocking and reactive approaches.

A full reactive stack is better than the blocking approach.

The blocking approach is better than the reactive approach.

In terms of user experience, which of the following statements is true?

In terms of user experience, which of the following statements is true?

May take longer as compared to getting it from a blocking API because of the extra processing

Is always faster than getting it from a blocking API

From a single client's perspective, getting all data from a reactive API __________.


From a single client’s perspective, getting all data from a reactive API __________.

Given a fixed number of available server threads less than the number of concurrent requests, what's the best approach in terms of served requests per second?

Given a fixed number of available server threads less than the number of concurrent requests, what’s the best approach in terms of served requests per second?

The classic MVC approach because of the extra processing required by WebFlux

WebFlux because it prevents the server threads bottleneck

Given a high concurrency of requests and a fixed number of available server threads less than the number of concurrent requests, which approach sends all the data to all the API clients faster?

Given a high concurrency of requests and a fixed number of available server threads less than the number of concurrent requests, which approach sends all the data to all the API clients faster?

The classic MVC approach gives better performance.

WebFlux still performs better because it makes better use of the threads.

Consider a scenario in which you change the available server threads to 100. Then, you run a test that executes 100 simultaneous requests to both the WebFlux and the classic MVC approach. Which of the following statements correctly describes the outcome?

Consider a scenario in which you change the available server threads to 100. Then, you run a test that executes 100 simultaneous requests to both the WebFlux and the classic MVC approach. Which of the following statements correctly describes the outcome?

The classic MVC approach performs better because the thread bottleneck is not there.

WebFlux performs better because a reactive stack is always faster.

Given a high concurrency of requests and a fixed number of available server threads lower than the number of concurrent requests, which approach sends all the data to all the API clients faster? 

> We are using a classic MVC approach with asynchronous processing, for example, by returning "Callable" objects.

Given a high concurrency of requests and a fixed number of available server threads lower than the number of concurrent requests, which approach sends all the data to all the API clients faster?
<blockquote>
We are using a classic MVC approach with asynchronous processing, for example, by returning “Callable” objects.
</blockquote>

It's not easy to switch to reactive programming paradigms, so it may slow down your organization at the beginning.

You may not get any benefit if your API clients are outside your organization and they don't consume the APIs in a reactive fashion.

What are some potential disadvantages of a full reactive stack?


What are some potential disadvantages of a full reactive stack?

Require you to use a special API to verify your reactive streams

Look exactly the same as unit tests that don't use a reactive approach 

In Project Reactor, unit tests ______________.


In Project Reactor, unit tests ______________.

WebFlux vs. the blocking approach quiz

WebFlux vs. the blocking approach quiz

Time for a quick quiz on the comparison between WebFlux and the blocking approach.

Reactive Web

Full Reactive Stack Backend

Connecting Angular With the WebFlux Backend

Conclusion

Appendix

Quiz: WebFlux vs. the Blocking Approach