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

# Benefits of non-blocking web calls

WebFlux implements a reactive, non-blocking API. That sounds pretty cool, but, what does that mean exactly? Why should we care about non-blocking web calls?


The first reason is _slow Internet connections_. Having a slow connection is annoying, but it gets even worse with classic blocking HTTP calls. Let’s say you’re searching for the best mobile phones on your favorite online store app. You enter the query terms and press "Search". Your Internet connection is slow, so you need to wait for 15 seconds, staring at a spinner or a blank page. 

Then, all at once, the full first page with results pops up. That happens because the web server doesn’t care about your slow connection, so it’s responding with a, let’s say, 300 kilobytes response of full JSON with summaries, descriptions, and prices of the first 50 items that match your criteria. 


On your side, *the client's side*, the problem is related to classic web client approaches that use blocking HTTP calls (even in different threads), that wait until the full HTTP response is received to process the data, and then render the page. A better alternative would be that the server, instead of returning the 50 items together, would send the items to the client one by one as soon as they're found. The client could then adapt its interface to react to these individual item pushes and render them as they come. 

> Note that switching only one of these two sides of the communication wouldn't fix this situation. Both sides would need to use a different approach.

## Deals with a busy server

Something similar to the slow Internet connection issue would happen if the server was busy. Let’s imagine that many users are searching for products on that online store at the same time, and the database's capacity is not ready for that. The database becomes slower, and the queries take a few seconds to fetch 50 results. Now, the bottleneck in the client-server interaction is not the web interface but the database connection. However, the result is the same. The user has to wait until the query is fully complete to get the list of products. A better outcome could be achieved if the database connection, instead of returning query results at once (blocking), opened streams with the database clients (another backend layer) and returned results as it found them.

## Provides better user experience

With a reactive web interface, the user would see three items on the screen per second instead of all at once after fifteen seconds. 

That’s the first non-blocking advantage: faster availability of the data, which, in our example, means **better user experience**. We, as developers, should aim for that and move away from blocking calls. According to [a study from Google](https://www.soasta.com/blog/google-mobile-web-performance-study/), up to 53% of mobile users abandon a site if it takes more than three seconds to load.

In a full reactive stack scenario, the database retrieves results as soon as they’re available. The same goes for the web interface (let’s say HTTP). The business logic layer should be prepared to process items in a reactive way too, e.g., by using reactive libraries. Finally, to close the loop and benefit from a full reactive stack, the client's side should be able to process the data as soon as it arrives, following a **subscriber pattern**.

## Provides better thread usage

There is an extra advantage that reactive web interfaces share with other asynchronous approaches: **a better thread usage**. In a non-blocking system, you don’t have threads waiting to be completed. Instead, the server _parks_ the client thread quickly, so there are fewer server threads occupied. Web clients will be notified when new data becomes available, following a *publish-subscribe* pattern. 

This advantage is very relevant if you have a server application that may perform slowly sometimes, thus accumulating a lot of blocked threads and, eventually, not being able to process any more.

Learn about the advantages of using the reactive web.

Reactive Web

Full Reactive Stack Backend

Connecting Angular With the WebFlux Backend

Conclusion

Appendix

Advantages of Using Reactive Web

Benefits of non-blocking web calls