<h2 id="introduction">Introduction</h2>
The main focus of this article is to help you understand how Spring's <a rel="nofollow noopener" target="_blank" href="https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/beans/factory/annotation/Value.html">@Value</a> annotation works.
<code>@Value</code> is a Java annotation that is used at the field or method/constructor parameter level and it indicates a default value for the affected argument. It is commonly used for injecting values into configuration variables - which we will show and explain in the next part of the article.
<h2 id="basicassignment">Basic Assignment</h2>
For the easiest examples, we will assign values to three different fields using the <code>@Value</code> annotation by giving them explicit values:
<pre><code class="hljs">@Value(&quot;John&quot;)
private String trainee;

@Value(&quot;100&quot;)
private int hoursOfCode;

@Value(&quot;true&quot;)
private boolean passedAssesmentTest;
</code></pre>
It's very important to note that the argument passed to the <code>@Value</code> annotation can only be a <code>String</code>. Spring will convert the value to the specified type and the assignment will be done without any problems - even if we are passing <code>String</code> values to <code>int</code> or <code>boolean</code> variables.
<h2 id="springenvironment">Spring Environment</h2>
Injecting values from properties files with the help of <code>@Value</code> annotation is probably the most used use-case in real-life applications.
We will use the default property file for Spring Boot - <code>application.properties</code>, where we can define variables that we can access afterwards:
<pre><code class="hljs">car.brand=Audi
car.color=Red
car.power=150
</code></pre>
<pre><code class="hljs">@Value(&quot;${car.brand&quot;)
private String brand;

@Value(&quot;${car.color}&quot;)
private String color;

@Value(&quot;${car.power}&quot;)
private int power;
</code></pre>
In this example, the values for the variables are being read from the <code>application.properties</code> file and assigned to them during bean creation.
Most of the time, we'd use this approach to inject configuration values from the <code>application.properties</code> file into beans.
<h2 id="defaultvalue">Default Value</h2>
Default values are used as a &quot;fallback&quot; if the property we wish to inject isn't defined or missing:
<pre><code class="hljs">@Value(&quot;${car.type:Sedan}&quot;)
private String type;
</code></pre>
In the above example, because we don't have any <code>car.type</code> property in <code>application.properties</code>, Spring will assign <code>Sedan</code> to the <code>type</code> variable as the default value.
If the <code>car.type</code> property gets inserted into the properties file, the new value will be used instead.
<h2 id="systemvariables">System Variables</h2>
We can also access system variables which are stored as properties by the Spring application at start:
<pre><code class="hljs">@Value(&quot;${user.name}&quot;)
// Or
@Value(&quot;${username}&quot;)
private String userName;

@Value(&quot;${number.of.processors}&quot;)
// Or
@Value(&quot;${number_of_processors}&quot;)
private int numberOfProcessors;

@Value(&quot;${java.home}&quot;)
private String java;
</code></pre>
The variables can be called with different naming conventions - Spring searches for us and assigns the correct value.
<h2 id="globalmethodvalue">Global Method Value</h2>
Because <code>@Value</code> is processed by the <code>BeanPostProcessor</code> class, it will be invoked when Spring is building the Spring context by instantiating configuration files and beans.
This means that by having <code>@Value</code> on a method, all the arguments will be mapped with the value provided to the annotation:
<pre><code class="hljs">@Value(&quot;${car.brand}&quot;)
public CarData setCarData(String color, String brand) {
 carData.setCarColor(color);
 carData.setCarBrand(brand);
}
</code></pre>
If we are printing <code>carData.getCarColor()</code> and <code>carData.getCarBrand()</code> we will get the <code>car.brand</code> value both times, because like we said, all arguments will be mapped with the value provided.
<h2 id="parametermethodvalue">Parameter Method Value</h2>
We can fix this by using <code>@Value</code> directly on the method parameter:
<pre><code class="hljs">@Value(&quot;${car.brand}&quot;)
public CarData setCarData(@Value(&quot;${car.color}&quot;) String color, String brand) {
 carData.setCarColor(color);
 carData.setCarBrand(brand);
}
</code></pre>
Now, if we are printing the values from the <code>carData</code> object - the color field will have the <code>car.color</code> value, because we provided the value to the parameter of the method itself.
<h2 id="springexpressionlanguagespel">Spring Expression Language (SpEL)</h2>
The Spring Expression Language (SpEL) is an expression language which serves as the foundation for expression evaluation within the Spring portfolio.
Basically, when using SpEL together with the <code>@Value</code> annotation, we are just changing the way we tell Spring what we need. Let's take a closer look:
<pre><code class="hljs">@Value(&quot;#{systemProperties[&#x27;user.name&#x27;]}&quot;)
private String userName;
</code></pre>
This is how you'd inject a specific system property. On the other hand, we could inject all properties by:
<pre><code class="hljs">@Value(&quot;#{systemProperties}&quot;)
private Map&lt;String, String&gt; properties;
</code></pre>
We know now, that we can use the <code>@Value</code> annotation for methods as a global value or as a parameter value.
Since constructors are essentially methods, we can use the annotation in constructors as well:
<pre><code class="hljs">public Driver(@Value(&quot;#{systemProperties[&#x27;user.name&#x27;]}&quot;) String name, String location) {
 this.name = name;
 this.location = location;
}
</code></pre>
<h2 id="injectingintomaps">Injecting into Maps</h2>
With SpEL, we can do some other fairly interesting things when coupled with the <code>@Value</code> annotation. For example, let's make a <code>Map</code> that represents <code>indoor</code> and <code>outdoor</code> hobbies of a student. Each of these can have multiple values:
<pre><code class="hljs">student.hobbies={indoor: &#x27;reading, drawing&#x27;, outdoor: &#x27;fishing, hiking, bushcraft&#x27;}
</code></pre>
Now, to inject this, we'll need a <code>Map&lt;String, List&lt;String&gt;&gt;</code>:
<pre><code class="hljs">@Value(&quot;#{${student.hobbies}}&quot;)
private Map&lt;String, List&lt;String&gt;&gt; hobbies;
</code></pre>
<h2 id="injectingintolists">Injecting into Lists</h2>
If a property has comma-separated-values, such as a simple list of books, we can use SpEL to interpret it and transform it into a list:
<pre><code class="hljs">student.booksRead=Harry Potter,The Hobbit,Game of Thrones
</code></pre>
By using the <code>split()</code> method, and splitting for every comma (<code>,</code>), we can inject these values into a list:
<pre><code class="hljs">@Value(&quot;#{&#x27;${student.booksRead}&#x27;.split(&#x27;,&#x27;)}&quot;)
private List&lt;String&gt; booksRead;
</code></pre>
<h2 id="conclusion">Conclusion</h2>
As soon as you end up working on a real application, you realize that configuration is an important topic and if you are using Spring. There's a big chance you already use or you will have to use the <code>@Value</code> annotation extensively.
Understanding this basic functionality is very important because if you don't, you might end up using it totally wrong.
We also need to be aware that not everything that looks simple is also very good for long term solutions. For example, we should only use <code>@Value</code> in encapsulated components/services (we can call them configuration services).
This way, we will have all our configurations in one place, and that component will only have the responsibility of loading and providing them to other components.

Guest Contributor

@Value is a Java annotation used at the field or method/constructor level. It's commonly used to inject values into configuration variables.

In this article, we'll cover the many ways you can use the @Value annotation.

The @Value Annotation in Spring

Hiram Kamau

With method overriding, inheriting classes may tweak how we expect a class to behave. In this article, we'll explore one of the core concepts of OOP - polymorphism, through method overriding.

Method Overriding in Java

<h3 id="introduction">Introduction</h3>
For most people, Bubble Sort is likely the first sorting algorithm they heard of in their Computer Science course.
It's highly intuitive and easy to &quot;translate&quot; into code, which is important for new software developers so they can ease themselves into turning ideas into a form that can be executed on a computer. However, Bubble Sort is one of the worst-performing sorting algorithms in every case except checking whether the array is already sorted, where it often outperforms more efficient sorting algorithms like <a target="_blank" href="/quicksort-in-python/">Quick Sort</a>.
<h3 id="theideabehindthebubblesort">The Idea Behind the Bubble Sort</h3>
The idea behind Bubble Sort is very simple, we look at pairs of adjacent elements in an array, one pair at a time, and swap their positions if the first element is larger than the second, or simply move on if it isn't. Let's look at an example and sort the array <code>[8, 5, 3, 1, 4, 7, 9]</code>:
<img src="https://stackabuse.s3.amazonaws.com/media/bubble-sort-in-java-1.gif" alt="bubble sort">
If you focus on the first number, the number <code>8</code>, you can see it &quot;bubbling up&quot; the array into the correct place. Then, this process is repeated for the number <code>5</code> and so on.
<h3 id="howtoimplementbubblesortinpython">How to Implement Bubble Sort in Python</h3>
With the visualization out of the way, let's go ahead and implement the algorithm. Again, it's extremely simple:
<pre><code class="hljs">def bubble_sort(our_list):
 # We go through the list as many times as there are elements
 for i in range(len(our_list)):
 # We want the last pair of adjacent elements to be (n-2, n-1)
 for j in range(len(our_list) - 1):
 if our_list[j] &gt; our_list[j+1]:
 # Swap
 our_list[j], our_list[j+1] = our_list[j+1], our_list[j]
</code></pre>
Now, let's populate a list and call the algorithm on it:
<pre><code class="hljs">our_list = [19, 13, 6, 2, 18, 8]
bubble_sort(our_list)
print(our_list)
</code></pre>
This will give us:
<pre><code class="hljs">[2, 6, 8, 13, 18, 19]
</code></pre>
<h4 id="optimization">Optimization</h4>
The simple implementation did its job, but there are two optimizations we can make here.
When no swaps are made, that means that the list is sorted. However, with the previously implemented algorithm, it'll keep evaluating the rest of the list even though it really doesn't need to. To fix this, we'll keep a <code>boolean</code> flag and check if any swaps were made in the previous iteration.
If no swaps are made, the algorithm should stop:
<pre><code class="hljs">def bubble_sort(our_list):
 # We want to stop passing through the list
 # as soon as we pass through without swapping any elements
 has_swapped = True

 while(has_swapped):
 has_swapped = False
 for i in range(len(our_list) - 1):
 if our_list[i] &gt; our_list[i+1]:
 # Swap
 our_list[i], our_list[i+1] = our_list[i+1], our_list[i]
 has_swapped = True
</code></pre>
The other optimization we can make leverages the fact that Bubble Sort works in such a way that the largest elements in a particular iteration end up at the end of the array.
The first time we pass through the list the position n is guaranteed to be the largest element, the second time we pass through the position n-1 is guaranteed to be the second-largest element, and so forth.
This means that with each consecutive iteration we can look at one less element than before. More precisely, in the k-th iteration, only need to look at the first n - k + 1 elements:
<pre><code class="hljs">def bubble_sort(our_list):
 has_swapped = True

 num_of_iterations = 0

 while(has_swapped):
 has_swapped = False
 for i in range(len(our_list) - num_of_iterations - 1):
 if our_list[i] &gt; our_list[i+1]:
 # Swap
 our_list[i], our_list[i+1] = our_list[i+1], our_list[i]
 has_swapped = True
 num_of_iterations += 1
</code></pre>
<h3 id="optimizedvsnonoptimizedbubblesort">Optimized vs Non-Optimized Bubble Sort</h3>
Let's go ahead and compare the time it takes for each of these code snippets to sort the same list a thousand times using the <code>timeit</code> module:
<pre><code class="hljs">Unoptimized Bubble Sort took: 0.0106407
</code></pre>
<pre><code class="hljs">Bubble Sort with a boolean flag took: 0.0078251
</code></pre>
<pre><code class="hljs">Bubble Sort with a boolean flag and shortened list took: 0.0075207
</code></pre>
<blockquote>
There isn't much of a difference between the latter two approaches due to the fact that the list is extremely short, but on larger lists - the second optimization can make a huge difference.
</blockquote>
<h3 id="conclusion">Conclusion</h3>
In the most inefficient approach, Bubble Sort goes through n-1 iterations, looking at n-1 pairs of adjacent elements. This gives it the time complexity of \)O(n^2)\), in both best-case and average-case situations. \)O(n^2)\) is considered pretty horrible for a sorting algorithm.
It does have an O(1) space complexity, but that isn't enough to compensate for its shortcomings in other fields.
However, it's still a big part of the software development community and history, and textbooks almost never fail to mention it when talking about basic sorting algorithms.

Olivera Popović

Dimitrije Stamenic

Although horribly inefficient, Bubble Sort is still a big part of the software development community and history. In this article, we'll be diving into a few approaches to Bubble Sorting lists in Python.

Bubble Sort in Python

Marcus Sanatan

Leodanis Pozo Ramos

The Python Template class is intended to be used for string substitution or string interpolation. The class works using regular expressions and allows for deep customization 

Formatting Strings with the Python Template Class

<h2 id="introduction">Introduction</h2>
JavaScript's Fetch API allows us to send HTTP requests. It's been a standard part of JavaScript since <a rel="nofollow noopener" target="_blank" href="http://www.ecma-international.org/ecma-262/6.0/">ECMAScript 2015</a> (commonly known as ES6) was introduced and uses Promises.
This article will first show you how requests were made with vanilla JavaScript before the Fetch API was developed. We will then guide you on how to use the Fetch API, highlighting how much of an improvement it is over other methods.
<h2 id="setup">Setup</h2>
This article looks at using the Fetch API to make HTTP requests in the browser. As such, we need to set up an HTML page that our browser can display. In your workspace, start by creating an <code>index.html</code> file.
The <code>index.html</code> file will be used throughout this article. The HTML page has no textual content, it will only be used to load the JS files so we can see the requests and responses in our browser's console:
<pre><code class="hljs">&lt;!DOCTYPE html&gt;
&lt;html lang=&quot;en&quot;&gt;

&lt;head&gt;
 &lt;meta charset=&quot;UTF-8&quot; /&gt;
 &lt;meta name=&quot;viewport&quot; content=&quot;width=device-width, initial-scale=1.0&quot; /&gt;
 &lt;meta http-equiv=&quot;X-UA-Compatible&quot; content=&quot;ie=edge&quot; /&gt;
 &lt;title&gt;JavaScript HTTP Requests&lt;/title&gt;
&lt;/head&gt;

&lt;body&gt;
 &lt;script src=&quot;./xhr.js&quot;&gt;&lt;/script&gt;
&lt;/body&gt;

&lt;/html&gt;
</code></pre>
We'll change the <code>script</code> tag as we're working through new topics, but the rest of the HTML will stay the same.
You will also want to have your browser console open so we can see the results of our HTTP requests. This is usually done by right-clicking on the web page and selecting &quot;Inspect&quot;. On Chrome it looks like this:
<img src="https://stackabuse.s3.amazonaws.com/media/using-fetch-to-send-http-requests-in-javascript-1.png" alt="The &quot;Inspect&quot; menu item when right-clicking in Chrome">
Now, let's select the &quot;Console&quot; tab so we can see any output that our JavaScript logs:
<img src="https://stackabuse.s3.amazonaws.com/media/using-fetch-to-send-http-requests-in-javascript-2.png" alt="The &quot;Console&quot; tab in our Developer Console">
You're all set! Let's begin sending HTTP requests with the first method possible with JavaScript - XMLHttpRequest.
<h2 id="requestswithxmlhttprequest">Requests with XMLHttpRequest</h2>
Before the Fetch API existed, all JavaScript requests were done with an <code>XMLHttpRequest</code> (or <code>XHR</code>) object. Despite its name, this object can retrieve data in any format from a server. It's not just limited to XML.
Let's get hands on with an XHR request in our browser. In the same folder as your <code>index.html</code> file, create a new <code>xhr.js</code> file.
This new JavaScript file will create an XHR object and send a <code>GET</code> request to a JSON API. We will then log the results of the request in the console. In your <code>xhr.js</code> file, enter the following:
<pre><code class="hljs">let xhr = new XMLHttpRequest();
xhr.open(&#x27;get&#x27;, &#x27;https://jsonplaceholder.typicode.com/posts/1&#x27;);
xhr.send();

xhr.onload = function() {
 console.log(xhr.response);
};
</code></pre>
In the first line, we created a new <code>XMLHttpRequest</code> object. We then used the <code>open()</code> method to create a new HTTP request. The first argument of <code>open()</code> is the HTTP method of the request - in this case, we are sending a <code>GET</code> request. The second argument is the URL with the server resource we want. We then use the <code>send()</code> method to dispatch the request.
When an <code>XHR</code> successfully gets data from the network, it sends a load event. To process the data after it's loaded, we set a function to the <code>onload</code> property of the <code>XHR</code> object. In this case, we simply log the response to the console.
Now, in your developer console you should see the following.
<img src="https://stackabuse.s3.amazonaws.com/media/using-fetch-to-send-http-requests-in-javascript-3.png" alt="JSON output of the XHR request for blog posts">
Good job on making an API request with <code>XMLHttpRequest</code>!
While serviceable, the way it handles asynchronous data is very different from the organized and standardized <a target="_blank" href="/promises-in-node-js/">Promises</a> used in modern JavaScript. We can maintain easier code with the Fetch API.
<h2 id="thefetchapi">The Fetch API</h2>
The Fetch API is a promise-based API for making HTTP requests, similar to what we did using <code>XMLHttpRequest</code>. Unlike <code>XMLHttpRequest</code> we do not have to create new objects when using the Fetch API. Browsers come with a global <code>fetch()</code> function that we can use to make requests.
Let's see how we can use this API to make HTTP requests over the Internet.
<h2 id="sendingrequestswithfetch">Sending Requests with Fetch</h2>
The Fetch API can make <code>GET</code>, <code>POST</code>, <code>PUT</code>, <code>PATCH</code>, <code>DELETE</code> and <a rel="nofollow noopener" target="_blank" href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods">other kinds of HTTP requests</a>. We'll focus on two of the most common methods used in HTTP requests: <code>GET</code> and <code>POST</code>.
<h3 id="getrequests">GET Requests</h3>
Let's use the Fetch API to make a <code>GET</code> request to <code>https://jsonplaceholder.typicode.com/posts/1</code> like we did with <code>XMLHttpRequest</code> earlier.
In your <code>index.html</code> file, change the <code>script</code> tag to reference a new JavaScript file:
<pre><code class="hljs">&lt;script src=&quot;./fetchGet.js&quot;&gt;&lt;/script&gt;
</code></pre>
Now create the new <code>fetchGet.js</code> file in the same workspace. We'll be sending a <code>GET</code> request and logging the output to the console once again. Enter the following code in <code>fetchGet.js</code>:
<pre><code class="hljs">fetch(&#x27;https://jsonplaceholder.typicode.com/posts/1&#x27;)
 .then(response =&gt; response.json())
 .then(json =&gt; console.log(json));
</code></pre>
In the first line we use the global <code>fetch()</code> function to send a <code>GET</code> request to our API. The argument of <code>fetch()</code> is the URL with the server-side resource.
We then chain the promise with the <code>then()</code> method, which captures the HTTP response in the <code>response</code> argument and calls its <code>json()</code> method. The <code>json()</code> method parses the response body to a JSON object. However, it returns that as a promise.
That's why we use <code>then()</code> once again to chain another promise, which logs the parsed JSON to the console.
Reload the <code>index.html</code> if needed so you can see the following output:
<img src="https://stackabuse.s3.amazonaws.com/media/using-fetch-to-send-http-requests-in-javascript-4.png" alt="JSON output of the fetch request for blog posts">
Note: The output would look different to what we got when we made the <code>GET</code> request with <code>XMLHttpRequest</code>. That's because <code>XMLHttpRequest</code> returns the HTTP response data as a string, whereas we parsed the data to a JSON object. While the returned formats are different, their contents are the same.
Let's see how we can use <code>fetch()</code> to send data in a <code>POST</code> request.
<h3 id="postrequests">POST Requests</h3>
We can upload data with <code>fetch()</code> by adding a JavaScript object as its second argument with the required information to send the HTTP request.
Let's use <code>fetch()</code> to upload JSON data in a <code>POST</code> request to a mock API. In your <code>index.html</code> file, change the <code>script</code> tag to reference a new JavaScript file:
<pre><code class="hljs">&lt;script src=&quot;./fetchPost.js&quot;&gt;&lt;/script&gt;
</code></pre>
Now create <code>fetchPost.js</code> in your workspace so we can make a <code>POST</code> request to the API that will upload a new to-do item as a JSON object. Type the code below in <code>fetchPost.js</code>:
<pre><code class="hljs">const todo = {
 title: &#x27;Some really important work to finish&#x27;
};

fetch(&#x27;https://jsonplaceholder.typicode.com/todos&#x27;, {
 method: &#x27;POST&#x27;,
 body: JSON.stringify(todo),
 headers: {
 &#x27;Content-type&#x27;: &#x27;application/json; charset=UTF-8&#x27;
 }
 })
 .then(response =&gt; response.json())
 .then(json =&gt; {
 console.log(json);
 });
</code></pre>
The first thing we do is create a <code>todo</code> object, which contains the data we'd like to send to the API.
As with <code>GET</code> requests, we use <code>fetch()</code> by providing a URL of the API we want to reach. However, this time we have an object as a second argument to <code>fetch()</code> with the following properties:
<ul>
<li><code>method</code>: A string that specifies with HTTP method to use in the request</li>
<li><code>body</code>: A string with any data we want to give to the server in our request</li>
<li><code>headers</code>: An object that allows us to add any headers we want our HTTP requests to include</li>
</ul>
As with the <code>GET</code> request, we process the server's response as JSON and log it to the developer console. Reloading our <code>index.html</code> should show us the following console output:
<img src="https://stackabuse.s3.amazonaws.com/media/using-fetch-to-send-http-requests-in-javascript-5.png" alt="JSON output of the fetch POST request to add a new &quot;todo&quot; item">
Great job using <code>fetch()</code> to upload data via <code>POST</code> request!
Now that we have a handle on making various HTTP requests with the Fetch API, let's see how we can handle different HTTP responses.
<h2 id="processingresponseswithfetch">Processing Responses with Fetch</h2>
So far we've been parsing the response data to JSON. While this works with the API used in the example, other responses may return different types of non-JSON data.
An HTTP response object that's returned after a successful <code>fetch()</code> request can be parsed to various formats. In addition to the <code>json()</code> method, we can use the following:
<ul>
<li><code>text()</code>: Returns the response as string data</li>
<li><code>blob()</code>: Returns the response as blob object (binary data along with its encoding)</li>
<li><code>formData()</code>: Return the response as <code>FormData</code> object (which stores key-value pairs of string data)</li>
<li><code>arrayBuffer()</code>: Return the response as <code>ArrayBuffer</code> (low-level representation of binary data)</li>
</ul>
Like the <code>json()</code> method, these functions return a promise with the content. Therefore, they must all be chained with a <code>then()</code> function so the content can be processed.
These functions are used to process successful HTTP responses that return data. Let's now have a look and how we can handle errors with the Fetch API.
<h2 id="handlinghttperrors">Handling HTTP Errors</h2>
As with any other promise, <code>fetch()</code> errors are handled in the <code>catch()</code> method that's placed at the end of a promise chain. However, the <code>catch()</code> function is only used if <code>fetch()</code> could not send a request. This typically means that there was a network error.
If we try to access a URL that does not exist and the server returns a 404, it would not be caught in the <code>catch()</code> method, as 404 is a valid HTTP response status.
Therefore, when handling errors with the Fetch API we need to do two things:
<ul>
<li>Include the <code>catch()</code> clause at the end of the promise chain to pick up any network errors</li>
<li>Check the HTTP status code of the response to see if it was successful or not.</li>
</ul>
Let's do another example where we try to get a URL that does not exist.
Using our <code>GET</code> request example, we can use <code>catch()</code> like this:
<pre><code class="hljs">fetch(&#x27;https://jsonplaceholder.typicode.com/posts/1&#x27;)
 .then(response =&gt; response.json())
 .then(json =&gt; console.log(json))
 .catch(err =&gt; console.error(err));
</code></pre>
However, the <code>catch()</code> function is only used if the <code>fetch()</code> request could not be sent. In your <code>index.html</code> file, change the script tag to reference a new JavaScript file:
<pre><code class="hljs">&lt;script src=&quot;./fetchError.js&quot;&gt;&lt;/script&gt;
</code></pre>
Now in your workspace create a new <code>fetchError.js</code> file. Enter the following code:
<pre><code class="hljs">fetch(&quot;https://jsonplaceholder.typicode.com/notreal/&quot;)
 .then(response =&gt; {
 if (!response.ok) {
 throw new Error(&quot;Could not reach website.&quot;);
 }
 return response.json();
 })
 .then(json =&gt; console.log(json))
 .catch(err =&gt; console.error(err));
</code></pre>
We begin by sending a <code>GET</code> request to a non-existent URL on that API. Note the change in the first <code>then()</code> function which parses the response body to JSON:
<pre><code class="hljs">if (!response.ok) {
 throw new Error(&quot;Could not reach website.&quot;);
}
</code></pre>
We check the <code>ok</code> property, which is boolean. It is <code>true</code> if the HTTP status code of the response is between 200-299. By using the not operator (<code>!</code>), we can capture the cases where the server returned an HTTP error. If we do get an HTTP error, we throw a custom error which would end the <code>fetch()</code> promise chain.
If we did not receive an HTTP error, we return the JSON response as a promise, like before.
At the end of the promise chain, we have a <code>catch()</code> function, which simply logs the error to the console.
If you reload your <code>index.html</code> page, you should see this console output:
<img src="https://stackabuse.s3.amazonaws.com/media/using-fetch-to-send-http-requests-in-javascript-6.png" alt="Error output trying to reach a fake URL">
Well done, you covered the fundamentals of the Fetch API.
<h2 id="conclusion">Conclusion</h2>
The Fetch API provides a promise-based way to send HTTP requests in JavaScript. Because it is promise-based, developers see it as a cleaner replacement to <code>XMLHttpRequest</code>.
With the <code>fetch()</code> function, we can make <code>GET</code> and <code>POST</code> requests to different URLs. We can configure a <code>fetch()</code> request to use any HTTP method we want to use.
The <code>fetch()</code> function also provides a <code>response</code> object that can be parsed into various formats. These include JSON, text, and bytes to name a few.
We also saw how we can handle errors when making requests with <code>fetch()</code>. Aside from putting the <code>catch()</code> method at the end of the promise chain to pick up network errors, we should also check the status code of the HTTP response we received before parsing its data.
The Fetch API makes external API calls manageable without the use of external libraries. What APIs are you planning to access with <code>fetch()</code>?

Arpan Abhishek

During software development, HTTP requests are made all the time. We'll be exploring the Fetch API - a modern, promise-based approach to HTTP requests.

Using fetch to Send HTTP Requests in JavaScript

<h2 id="introduction">Introduction</h2>
<a rel="nofollow noopener" target="_blank" href="https://www.heroku.com/">Heroku</a> is a popular Platform-as-a-Service (PaaS) that allows developers to run and deploy applications by availing the infrastructure required in terms of hardware and software.
This means that we do not have to invest in the hardware and software needed to expose our applications to end-users and this freedom allows us to concentrate on our business logic instead of deployment.
In this post, we will outline how to deploy a simple Django application to a Heroku pipeline. It targets existing Python developers and assumes a basic understanding of setting up and running a Django application.
<h2 id="prerequisites">Prerequisites</h2>
For this post, we'll need:
<ul>
<li>A free-tier <a rel="nofollow noopener" target="_blank" href="https://signup.heroku.com/">Heroku account</a>,</li>
<li>Python 3+ and Virtualenv installed</li>
<li><a rel="nofollow noopener" target="_blank" href="https://git-scm.com/book/en/v2/Getting-Started-Installing-Git">Git</a> installed and a GitHub account.</li>
</ul>
<h2 id="demoapplication">Demo Application</h2>
<h3 id="bootstrappingthedjangoapp">Bootstrapping the Django App</h3>
Before deploying our Django application, we will need to prepare it as per Heroku's requirements. We will start by creating a virtual environment, activating it and installing the required packages, and finally bootstrapping a simple Django application:
<pre><code class="hljs">$ virtualenv --python=python3 env --no-site-packages
$ source env/bin/activate
$ pip install django gunicorn
$ django-admin startproject plaindjango
</code></pre>
If everything goes well, we should have the following landing page running on our local server:
<img src="https://stackabuse.s3.amazonaws.com/media/deploying-a-django-application-to-heroku-from-github-1.png" alt="django app bootstrap">
At this point, the folder structure of our project is:
<pre><code class="hljs">$ cd plaindjango &amp;&amp; tree .
.
├── manage.py
└── plaindjango
 ├── __init__.py
 ├── asgi.py
 ├── settings.py
 ├── urls.py
 └── wsgi.py

1 directory, 6 files
</code></pre>
Before we deploy to Heroku, we will need to make some changes. First, we need to change the <code>ALLOWED_HOSTS</code> setting in our <code>plaindjango/settings.py</code> to:
<pre><code class="hljs">ALLOWED_HOSTS = [&#x27;*&#x27;]
</code></pre>
This setting defines the hosts or domains that our Django application can serve. It is a security measure against <a rel="nofollow noopener" target="_blank" href="https://docs.djangoproject.com/en/3.0/topics/security/#host-headers-virtual-hosting">HTTP Header host attacks</a>, but since ours is a simple demonstration project, we will allow all hosts by adding <code>'*'</code> in the list.
The next change we need to make is to specify a folder for our static files through the <code>STATIC_ROOT</code> setting:
<pre><code class="hljs">STATIC_ROOT = os.path.join(BASE_DIR, &#x27;static&#x27;)
</code></pre>
When Heroku is deploying our application, it runs the command <code>django-admin collectstatic</code>, which bundles and saves all static files in the specified folder. This folder will be in our project's root directory.
<h3 id="preparingtheappfordeployment">Preparing the App for Deployment</h3>
With our Django application ready, Heroku requires us to include the following files in our project root so that it can be ready for deployment:
<ol>
<li><code>runtime.txt</code></li>
</ol>
The purpose of this file is to specify the Python version that will be used to run our project. In our case, the file will just contain:
<pre><code class="hljs">python-3.7.6
</code></pre>
<ol start="2">
<li><code>Procfile</code></li>
</ol>
This file specifies the commands to be executed when the program is starting up.
While setting up, we installed <a rel="nofollow noopener" target="_blank" href="https://gunicorn.org/">Gunicorn</a> ('Green Unicorn') which is a pure-Python WSGI (Web Server Gateway Interface) server for UNIX.
While Django ships with its own WSGI server, our Profile will tell Heroku to use Gunicorn to serve our application. The contents of this file will be:
<pre><code class="hljs">web: gunicorn plaindjango.wsgi:application --log-file -
</code></pre>
This line tells Heroku that ours is a <code>web</code> process or application that will be started by using <code>gunicorn</code>. <code>Gunicorn</code> will then use the WSGI file of our project to start our application server.
<ol start="3">
<li><code>requirements.txt</code></li>
</ol>
Finally, we need the <code>requirements.txt</code> file that defines the requirements of our Django application. We can create this in our virtual environment by executing the following command:
<pre><code class="hljs">$ pip freeze &gt; requirements.txt
</code></pre>
The final folder structure of our Django application containing the extra files will now be:
<pre><code class="hljs">$ tree .
.
├── Procfile
├── manage.py
├── plaindjango
│ ├── __init__.py
│ ├── wsgi.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
├── requirements.txt
└── runtime.txt

1 directory, 9 files
</code></pre>
With these files in place, our application is ready for Heroku.
<h3 id="deployingtoherokuviagithub">Deploying to Heroku via GitHub</h3>
While Heroku offers its own Git platform that we can use for our deployments, it is not as feature-rich as GitHub. Heroku also allows us to pull our code from GitHub and deploy it.
Our code is ready for deployment, so we can go ahead and <a rel="nofollow noopener" target="_blank" href="https://github.com/new/">create a GitHub repository</a> and push our code.
For reference, here is <a rel="nofollow noopener" target="_blank" href="https://github.com/ro6ley/plaindjango">a sample Django application on GitHub</a> that is ready for deployment on Heroku.
With our work ready on GitHub, let us head over to Heroku and create a new pipeline using the &quot;New&quot; button on the top right side of our Heroku dashboard.
We provide the name of our pipeline and the GitHub repository to connect to:
<img src="https://stackabuse.s3.amazonaws.com/media/deploying-a-django-application-to-heroku-from-github-2.png" alt="creating a django pipeline">
A pipeline represents a group of Heroku applications that share the same codebase. In a pipeline, we can define different stages in a continuous delivery workflow.
This means that, through Heroku, we can deploy our code to our production, staging, and development environments at the same time, all from GitHub.
When using GitHub as the source of our application, we can configure Heroku pipelines to deploy code from different branches to different environments.
For instance, the code in our &quot;master&quot; branch will be deployed to the production environment, the &quot;staging&quot; branch to our staging environment and the &quot;dev&quot; branch to our development environment.
This gives us visibility over our project across multiple stages enhancing our delivery.
Heroku pipelines have a feature called &quot;Review Apps&quot; that allows us to deploy Pull Requests as standalone applications. With this enabled, we can verify the work in pull requests without having to pull the changes locally and testing them.
<h3 id="theherokupipeline">The Heroku Pipeline</h3>
This is the view of our recently created pipeline for our application on GitHub:
<img src="https://stackabuse.s3.amazonaws.com/media/deploying-a-django-application-to-heroku-from-github-3.png" alt="pipeline landing page">
The pipeline has two stages by default and a section to enable review apps. Since all of our code currently resides on the &quot;master&quot; branch, let us go ahead and deploy the branch by clicking on &quot;Add app&quot; under the production stage:
<img src="https://stackabuse.s3.amazonaws.com/media/deploying-a-django-application-to-heroku-from-github-4.png" alt="creating the production app">
Heroku allows us to add existing applications to a pipeline or create a new one. Since this is a new pipeline, we will create a new application called <code>plaindjango-production</code> that will be our production environment.
This results in:
<img src="https://stackabuse.s3.amazonaws.com/media/deploying-a-django-application-to-heroku-from-github-5.png" alt="ready production app">
Our production application has been created but our code is not yet running. The next step is to choose the branch from which the code will be deployed to our production environment:
<img src="https://stackabuse.s3.amazonaws.com/media/deploying-a-django-application-to-heroku-from-github-6.png" alt="choose branch">
Once we click on &quot;Deploy&quot;, Heroku will pull our code from the &quot;master&quot; branch and deploy it. We can view the progress of the deployment by viewing the logs and once the application is deployed, we will receive a link to our running application:
<img src="https://stackabuse.s3.amazonaws.com/media/deploying-a-django-application-to-heroku-from-github-7.png" alt="successful logs">
At the very end of the logs, there is a link to our running application. When we access the link, we are welcomed by our Django landing page:
<img src="https://stackabuse.s3.amazonaws.com/media/deploying-a-django-application-to-heroku-from-github-8.png" alt="production deployment">
We have successfully deployed our production Django application to Heroku via GitHub. To create an app for our staging environment, the same steps are taken as for the master environment.
We will start by creating a &quot;staging&quot; branch on GitHub via the terminal:
<pre><code class="hljs">$ git checkout -b staging &amp;&amp; git push origin staging
</code></pre>
Finally, an application is added to the project and a pull request is created from the &quot;staging&quot; branch to the &quot;master&quot; branch.
The pull request can be seen <a rel="nofollow noopener" target="_blank" href="https://github.com/ro6ley/plaindjango/pull/1">here on GitHub</a>, and this is the result on our Heroku pipeline:
<img src="https://stackabuse.s3.amazonaws.com/media/deploying-a-django-application-to-heroku-from-github-9.png" alt="pull request deployed">
We can see a new application has been created for our pull request and when we open it, we can see the changes that the pull request introduces to our project:
<img src="https://stackabuse.s3.amazonaws.com/media/deploying-a-django-application-to-heroku-from-github-10.png" alt="pull request changes live">
Our pull request has been deployed successfully and we can review it before merging the changes into master. With automatic deployments activated, Heroku will deploy our changes once we merge the pull request into the master branch and the changes will go live automatically.
<h2 id="conclusion">Conclusion</h2>
Our Django application has been deployed to Heroku from GitHub using a pipeline. While this is not the only way to deploy a Django application to Heroku, it the most suitable for a collaborative project.
Containerized applications can be deployed on Heroku by building Docker images and either publishing them to Dockerhub or Heroku's own container registry. More information about deploying Dockerized applications to Heroku can be found in the <a target="_blank" rel="nofollow noopener" href="https://devcenter.heroku.com/categories/deploying-with-docker">official documentation</a>. Heroku also provides a Git platform that can be used to deploy applications in conjunction with their CLI tool.
With integration to git and GitHub's functionality to allow the deployment of containerized applications, Heroku is a capable platform to handle your development needs. The platform also provides <a rel="nofollow noopener" target="_blank" href="https://devcenter.heroku.com/categories/add-ons">add-ons</a> through a marketplace.
These add-ons are services or pieces of infrastructure that can be used to enhance our applications. Such add-ons allow us to integrate our application to databases and datastores including PostgreSQL, MySQL, and Redis.
There is more to be achieved with Django applications on Heroku, and this post was meant to present a simple view into how to deploy a Django application to the platform in a way that suits our daily workflow.
The Heroku-ready Django project can be found <a rel="nofollow noopener" target="_blank" href="https://github.com/ro6ley/plaindjango">here on GitHub</a> as well as the open pull request that was also deployed.

Robley Gori

In this article, we'll outline the deployment of a Django application to a Heroku pipeline from a GitHub repository.

Deploying Django Apps to Heroku from GitHub

<h2 id="introduction">Introduction</h2>
In software testing, a &quot;spy&quot; records how a function is used when it is tested. This includes how many times it was called, whether it was called with the correct arguments, and what was returned.
While tests are primarily used to validate the output of a function, sometimes we need to validate how a function interacts with other parts of the code.
In this article, we'll have a deeper look into what spies are and when they should be used. We will then spy on a HTTP request while using <a rel="nofollow noopener" target="_blank" href="https://sinonjs.org/">Sinon.js</a> in a JavaScript unit test.
This article is the second of a series about testing techniques with Sinon.js. We recommend you read our previous article as well:
<ul>
<li><a target="_blank" href="/using-stubs-for-testing-in-javascript-with-sinon-js">Using Stubs for Testing in JavaScript with Sinon.js</a></li>
<li>Using Spies for Testing in JavaScript with Sinon.js (you are here)</li>
<li><a target="_blank" href="/using-mocks-for-testing-in-javascript-with-sinon-js/">Using Mocks for Testing in JavaScript with Sinon.js</a></li>
</ul>
<h2 id="whatarespies">What are Spies?</h2>
A spy is an object in testing that tracks calls made to a method. By tracking its calls, we can verify that it is being used in the way our function is expected to use it.
True to its name, a spy gives us details about how a function is used. How many times was it called? What arguments were passed into the function?
Let's consider a function that checks if a user exists, and creates one in our database if it doesn't. We may stub the database responses and get the correct user data in our test. But how do we know that the function is actually creating a user in cases we don't have pre-existing user data? With a spy, we will observe how many times the create-user function is called and be certain.
Now that we know what a spy is, let's think about the situations where we should use them.
<h2 id="whyusespies">Why Use Spies?</h2>
Spies excel in giving insight into the behavior of the function we are testing. While validating the inputs and outputs of a test is crucial, examining how the function behaves can be crucial in many scenarios:
When your function has side effects that are not reflected in its results, you should spy on the methods it uses.
An example would be a function that returns JSON to a user after making many calls to various external APIs. The final JSON payload does not tell the user how the function retrieves all its data. A spy that monitors how many times it called the external APIs and what inputs it used in those calls would tell us how.
Let's look at how we can use Sinon.js to create spies in our code.
<h2 id="usingsinonjstocreateaspy">Using Sinon.Js to Create a Spy</h2>
There are multiple ways to create a spy with Sinon.js, each with their advantages and disadvantages. This tutorial will focus on the following two methods, which target spies on a single function at a time:
<ol>
<li>An anonymous function that tracks arguments, values, and calls made to a method.</li>
<li>A wrapper to an existing function.</li>
</ol>
First, let's set up our project so we can run our test files and use Sinon.js.
<h3 id="setup">Setup</h3>
Let's begin by creating a folder to store our JavaScript code. Create a new folder and move into it:
<pre><code class="hljs">$ mkdir SpyTests
$ cd SpyTests
</code></pre>
Initialize NPM so you can keep track of the packages you install:
<pre><code class="hljs">$ npm init -y
</code></pre>
Now let's install our testing dependencies. We install <a rel="nofollow noopener" target="_blank" href="https://mochajs.org/">Mocha</a> and <a rel="nofollow noopener" target="_blank" href="https://www.chaijs.com/">Chai</a> to run our tests, along with Sinon.js:
<pre><code class="hljs">$ npm i mocha chai sinon --save-dev
</code></pre>
Our setup is complete! Let's begin by using spies as anonymous functions.
<h3 id="spieswithanonymousfunctions">Spies with Anonymous Functions</h3>
As anonymous functions, Sinon.js spies are often useful in cases where we want to test higher-order functions that take other functions, i.e callbacks as arguments. Let's look at a basic example that re-implements the <code>Array.prototype.map()</code> with a callback:
Create two files i.e <code>mapOperations.js</code> and <code>mapOperations.test.js</code> inside the <code>spyTests</code> directory as follows:
<pre><code class="hljs">$ touch mapOperations.js mapOperations.test.js
</code></pre>
Enter the following code in the <code>mapOperations.js</code> file:
<pre><code class="hljs">const map = (array, operation) =&gt; {
 let arrayOfMappedItems = [];
 for (let item of array) {
 arrayOfMappedItems.push(operation(item));
 }
 return arrayOfMappedItems;
};

console.log(map([{ name: &#x27;john&#x27;, role: &#x27;author&#x27;}, { name: &#x27;jane&#x27;, role: &#x27;owner&#x27;}], user =&gt; user.name));

module.exports = { map };
</code></pre>
In the code above, <code>map()</code> takes an array as its first argument and a callback function, <code>operation()</code>, that transforms the array items as its second argument.
Inside the <code>map()</code> function, we iterate through the array and apply the operation on each array item, then push the result to the <code>arrayOfMappedItems</code> array.
When you run this example on the console, you should get the following result:
<pre><code class="hljs">$ node mapOperations.js
[ &#x27;john&#x27;, &#x27;jane&#x27; ]
</code></pre>
To test whether the <code>operation()</code> function was called by our <code>map()</code> function, we can create and pass an anonymous spy to the <code>map()</code> function as follows:
<pre><code class="hljs">const { map } = require(&#x27;./mapOperations&#x27;);
const sinon = require(&#x27;sinon&#x27;);
const expect = require(&#x27;chai&#x27;).expect;

describe(&#x27;test map&#x27;, () =&gt; {
 const operation = sinon.spy();

 it(&#x27;calls operation&#x27;, () =&gt; {
 map([{ name: &#x27;foo&#x27;, role: &#x27;author&#x27;}, { name: &#x27;bar&#x27;, role: &#x27;owner&#x27;}], operation);
 expect(operation.called);
 });
});
</code></pre>
While our callback does not actually transform the array, our spy can verify that the function we are testing actually uses it. This is confirmed when <code>expect(operation.called);</code> does not fail the test.
Let's see if our test passes! Run the test, you should get the following output:
<pre><code class="hljs">$ mocha mapOperations.test.js

 test map

 ✓ calls operation


 1 passing (4ms)

✨ Done in 0.58s.
</code></pre>
It works! We are now sure that our function will use whatever callback we put in its arguments. Let's now see how we can wrap a function or method using a spy.
<h3 id="spiesasfunctionormethodwrappers">Spies as Function or Method Wrappers</h3>
In the <a target="_blank" href="/using-stubs-for-testing-in-javascript-with-sinon-js">previous article</a>, we saw how we can stub an HTTP request in our unit tests. We will use the same code to show how we can use Sinon.js to spy on an HTTP request.
In a new file called <code>index.js</code>, add the following code:
<pre><code class="hljs">const request = require(&#x27;request&#x27;);

module.exports = {
 getAlbumById: async function(id) {
 const requestUrl = `https://jsonplaceholder.typicode.com/albums/${id}/photos?_limit=3`;
 return new Promise((resolve, reject) =&gt; {
 request.get(requestUrl, (err, res, body) =&gt; {
 if (err) {
 return reject(err);
 }
 resolve(JSON.parse(body));
 });
 });
 }
};
</code></pre>
To recap, the <code>getAlbumById()</code> method calls a JSON API that fetches a list of photos from an album whose ID we pass as a parameter. Previously, we stubbed the <code>request.get()</code> method to return a fixed list of photos.
This time, we will spy on the <code>request.get()</code> method so we can verify that our function makes an HTTP request to the API. We'll also check that it made the request once, which is good as we don't want a bug that spams the API's endpoint.
In a new test file called <code>index.test.js</code>, write the following JavaScript code line by line:
<pre><code class="hljs">const expect = require(&#x27;chai&#x27;).expect;
const request = require(&#x27;request&#x27;);
const sinon = require(&#x27;sinon&#x27;);
const index = require(&#x27;./index&#x27;);

describe(&#x27;test getPhotosByAlbumId&#x27;, () =&gt; {
 let requestSpy;
 before(() =&gt; {
 requestSpy = sinon.spy(request, &#x27;get&#x27;);
 });

 after(() =&gt; {
 request.get.restore();
 });

 it(&#x27;should getPhotosByAlbumId&#x27;, (done) =&gt; {
 index.getAlbumById(2).then((photos) =&gt; {
 expect(requestSpy.calledOnce);
 expect(requestSpy.args[0][0]).to.equal(&quot;https://jsonplaceholder.typicode.com/albums/2/photos?_limit=3&quot;);
 photos.forEach(photo =&gt; {
 expect(photo).to.have.property(&#x27;id&#x27;);
 expect(photo).to.have.property(&#x27;title&#x27;);
 expect(photo).to.have.property(&#x27;url&#x27;);
 });
 done();
 });
 });
});
</code></pre>
In the above test, we wrapped the <code>request.get()</code> method with a spy during setup in the <code>before()</code> function. We restore the function when we teardown the test in the <code>after()</code> function.
In the test case, we made the assertion that <code>requestSpy</code>, the object that tracks <code>request.get()</code>'s usage, only records one call. We then go deeper to confirm that its first argument of the <code>request.get()</code> call is the URL of the JSON API. We then made assertions to ensure that photos returned have the expected properties.
When you run the test, you should get the following output:
<pre><code class="hljs">$ mocha index.test.js


 test getPhotosByAlbumId
 ✓ should getPhotosByAlbumId (570ms)


 1 passing (587ms)

✨ Done in 2.53s.
</code></pre>
Please note that this test made an actual network request to the API. The spy wraps around the function, it does not replace its functionality!
Also, Sinon.js test stubs are already spies! If you ever create a test stub, you will be able to see how many time it was called and the arguments that were passed to the function.
<h2 id="conclusion">Conclusion</h2>
A spy in testing gives us a way of tracking calls made to a method so that we can verify that it works as expected. We use spies to check whether a method was called or not called, how many times it was called, with what arguments it was called, and also the value it returned when called.
In this article, we introduced the concept of spies and saw how we can use Sinon.js to create spies. We also looked at how we can create spies as anonymous functions, and how we can use them to wrap methods. For more advanced use cases, Sinon.js provides a rich spy API which we can leverage. For more details, the documentation can be accessed <a rel="nofollow noopener" target="_blank" href="https://sinonjs.org/releases/latest/spies/">here</a>.

Allan Mogusu

Sinon.js is a popular framework used in standalone test spies, stubs and mocks for JavaScript. In this article, we'll spy on an HTTP request in a unit test.

Using Spies for Testing in JavaScript with Sinon.js

Janith Kasun

MongoDB is a cross-platform, document-oriented database management system (DBMS). Being a JSON-like NoSQL database, it works very well with JavaScript.

A Beginner-Level Introduction to MongoDB with Node.js

<h2 id="introduction">Introduction</h2>
<a rel="nofollow noopener" target="_blank" href="https://docs.spring.io/spring-framework/docs/5.0.0.BUILD-SNAPSHOT/spring-framework-reference/html/web-reactive.html">Spring WebFlux</a> is Spring's response to the rising issue of blocking I/O architecture.
As data is becoming more and more crucial in our age, the approaches we take to retrieve and manipulate it changes. Conventionally, most approaches were &quot;blocking&quot;, or rather, synchronous. What this means is that accessing a resource blocked the application from accessing/processing another one until the previous resource was dealt with.
This was perfectly fine with a limited amount of data and resources, though with rising demand for data through high-performance applications - this became a huge problem.
Publishers started overwhelming subscribers and handling resources one-by-one, just like having a single clerk work in the whole supermarket, became too slow for a smooth user experience.
The solution is obvious - have more clerks handle the customers. In terms of software applications, this means a multi-threaded environment and asynchronous, non-blocking calls.
<h3 id="springreactivestack">Spring Reactive Stack</h3>
Spring's popular servlet stack comprising of Spring MVC uses the conventional methods of accessing and processing data as synchronous calls. With the introduction of Spring 5, Spring's reactive stack was built on top of <a rel="nofollow noopener" target="_blank" href="https://github.com/reactor/reactor-core">Reactor Core</a>.
Spring's reactive stack offers additional support for <a rel="nofollow noopener" target="_blank" href="https://netty.io/">Netty</a> and Servlet 3.1+ containers, giving increased performances for reactive applications:
<img src="https://stackabuse.s3.amazonaws.com/media/guide-to-spring-5-webflux-reactive-programming-1.png" alt="spring webflux reactor"> 
Credit <a rel="nofollow noopener" target="_blank" href="https://spring.io">Spring</a>
<h2 id="springwebflux">Spring WebFlux</h2>
Spring WebFlux is a counterpart module for Spring MVC. Where Spring MVC implements synchronous, blocking I/O, Spring WebFlux implements reactive programming via <a rel="nofollow noopener" target="_blank" href="https://www.reactive-streams.org">Reactive Streams</a>.
You'll typically use one or the other, though you're also free to combine them together.
<h3 id="springwebfluxdependencies">Spring WebFlux Dependencies</h3>
With a plain Spring Boot project initialized through <a rel="nofollow noopener" target="_blank" href="https://start.spring.io/">Spring Initializr</a>, it's enough to add a single dependency:
<pre><code class="hljs">&lt;dependency&gt;
 &lt;groupId&gt;org.springframework.boot&lt;/groupId&gt;
 &lt;artifactId&gt;spring-boot-starter-webflux&lt;/artifactId&gt;
 &lt;version&gt;{version}&lt;/version&gt;
&lt;/dependency&gt;
</code></pre>
The <code>spring-boot-starter-webflux</code> includes <code>spring-web</code>, <code>spring-webflux</code>, <code>spring-boot-starter</code>, <code>spring-boot-starter-reactor-netty</code>, etc., so there's no need for any other dependency to be present.
For the applications using Gradle for dependency management, Spring WebFlux can be added in the application's <code>build.gradle</code> file:
<pre><code class="hljs">compile group: &#x27;org.springframework.boot&#x27;, name: &#x27;spring-boot-starter-webflux&#x27;, version: &#x27;2.2.2.RELEASE&#x27;
</code></pre>
<h2 id="monoandflux">Mono and Flux</h2>
In Spring WebFlux, the data returned from any operation is packed into a reactive stream. There are two types that embody this approach and are the building blocks in WebFlux applications - <code>Mono</code> and <code>Flux</code>.
<code>Mono</code> is a stream which returns zero items or a single item (<code>0..1</code>), whereas <code>Flux</code> is a stream which returns zero or more items (<code>0..N</code>).
<code>Mono</code> is therefore used when you're expecting a single (or none) result, such as retrieving a unique user from the database, whereas <code>Flux</code> is used when you're expecting multiple results or a collection of some sort.
<h2 id="springwebfluxcontroller">Spring WebFlux Controller</h2>
Similar to how we use controllers in classic Spring MVC, for creation of asynchronous REST APIs, we use WebFlux controller. Even the naming conventions are similar to ensure an easy transition between these two approaches.
To mark a class as a controller, we use the <code>@RestController</code> annotation on a class level.
Having Spring WebFlux and the Reactor Core dependencies in the class path will let Spring know that the <code>@RestController</code> is in fact a reactive component and add support for <code>Mono</code> and <code>Flux</code>.
<h2 id="springwebfluxconfiguration">Spring WebFlux Configuration</h2>
As is standard with Spring Boot, we'll handle the configuration through annotations. The <code>@Configuration</code> and <code>@EnableWebFlux</code> annotations mark a class as a configuration class and Spring's bean management will register it:
<pre><code class="hljs">@Configuration
@EnableWebFlux 
public class WebFluxConfig {}
</code></pre>
To use or extend the existing WebFlux configuration API, you can extend the <code>WebFluxConfigurer</code> interface:
<pre><code class="hljs">@Configuration
@EnableWebFlux 
public class WebFluxConfig implements WebFluxConfigurer {}
</code></pre>
<h2 id="corswithspringwebflux">CORS with Spring WebFlux</h2>
WebFlux also offers CORS (Cross-Origin Resource Sharing) support, very similar to the Spring MVC servlet stack. The CORS configuration can be set at project level, as well as controller and controller method levels.
To add the CORS configuration at project level you need to <code>@Overrride</code> the <code>addCorsMappings()</code> method from the <code>WebFluxConfigurer</code> interface:
<pre><code class="hljs">@Configuration
@EnableWebFlux 
public class WebFluxConfig implements WebFluxConfigurer { 
 @Override
 public void addCorsMappings(CorsRegistry registry) {
 registry.addMapping(&quot;/api/**&quot;)
 .allowedOrigins(&quot;http://www.stackabuse.com&quot;)
 .allowedMethods(&quot;GET&quot;, &quot;PUT&quot;, &quot;DELETE&quot;)
 .allowedHeaders(&quot;testHeader&quot;)
 .allowCredentials(true);
 }
}
</code></pre>
And for adding CORS configuration at a more granular level, the <code>@CrossOrigin</code> annotation is used. This allows for specifying CORS details at controller and method level.
When <code>@CrossOrigin</code> is used at the controller class level, all the method level CORS settings inherit from the class level configuration:
<pre><code class="hljs">@CrossOrigin(origins = &quot;https://www.stackabuse.com&quot;)
@RestController
@RequestMapping(&quot;/resource&quot;) 
public class ResourceController {

 @GetMapping(&quot;/{id}&quot;)
 public Mono&lt;Resource&gt; getResource(@PathVariable String id) {

 }
}
</code></pre>
<h2 id="securitywithspringwebflux">Security with Spring Webflux</h2>
Spring also offers the standard security options for its WebFlux framework. You need to add <code>@EnableWebFluxSecurity</code> at the class level to enable the security configurations in the project:
<pre><code class="hljs">@EnableWebFluxSecurity
public class WebfluxSecurity {

 @Bean
 public SecurityWebFilterChain springSecurityFilterChain(
 ServerHttpSecurity http) {
 http.csrf().disable()
 .authorizeExchange()
 .pathMatchers(HttpMethod.GET, &quot;/resource/&quot;).hasRole(&quot;ADMIN&quot;)
 .pathMatchers(&quot;/**&quot;).permitAll()
 .and()
 .httpBasic();
 return http.build();
 }
}
</code></pre>
<h2 id="springwebfluxwebclient">Spring WebFlux Web Client</h2>
Spring WebFlux also includes a reactive web client for managing REST calls. <a rel="nofollow noopener" target="_blank" href="https://github.com/reactor/reactor-netty">Reactor-Netty</a> is used as default for communicating with the WebFlux server.
The WebFlux client object can be created using either static factory methods or through its builder method (more customization).
The static factory methods are <code>WebClient.create()</code> and <code>WebClient.create(String baseUrl)</code>. On the other hand the <code>WebClient.builder</code> offers following <a rel="nofollow noopener" target="_blank" href="https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#webflux-client">options</a> to add more details to the web client object:
<ul>
<li><code>uriBuilderFactory</code></li>
<li><code>defaultHeader</code></li>
<li><code>defaultCookie</code></li>
<li><code>defaultRequest</code></li>
<li><code>filter</code></li>
<li><code>exchangeStrategies</code></li>
<li><code>clientConnector</code></li>
</ul>
We'll take a closer look at this in the proceeding section where a demo application is built.
<h2 id="demoapplication">Demo Application</h2>
We'll be creating a simple reactive REST API using WebFlux's standard components, which will act as a reactive server. Then, a reactive web client application will be built, which retrieves information from this server and processes the data.
<h2 id="webfluxwebserver">WebFlux Web Server</h2>
<h3 id="repository">Repository</h3>
Let's start by laying down the foundation for a reactive application by creating a reactive repository interface.
<pre><code class="hljs">public interface ResourceRepository extends ReactiveCrudRepository&lt;Resource, String&gt; {}
</code></pre>
We have extended our repository from WebFlux's <code>ReactiveCrudRepository</code>, which will return data as <code>Mono</code> or <code>Flux</code> datatypes, depending on the number of elements which can be retrieved.
To use <a target="_blank" href="/spring-data-mongodb-tutorial/">MongoDB</a> with Spring WebFlux, we'll add a configuration class which tells Spring that the database should be handled as a reactive component:
<pre><code class="hljs">@EnableReactiveMongoRepositories
public class MongoDbConfiguration extends AbstractReactiveMongoConfiguration {

 @Override
 public MongoClient reactiveMongoClient() {
 return MongoClients.create();
 }

 @Override
 protected String getDatabaseName() {
 return &quot;testDatabase&quot;;
 }
}
</code></pre>
<h3 id="controller">Controller</h3>
With our data layer done and configured, let's create a simple REST controller which will retrieve <code>Mono</code> and <code>Flux</code> resources through GET requests:
<pre><code class="hljs">@RestController
@RequestMapping(&quot;/resource&quot;)
public class ResourceController {

 @Autowired
 ResourceRepository resourceRepository;

 @GetMapping(&quot;/{id}&quot;)
 public Mono&lt;Resource&gt; getResource(@PathVariable String id) {
 return resourceRepository.findById(id);
 }

 @GetMapping
 public Flux&lt;Resource&gt; getResources() {
 return resourceRepository.findAll();
 }
}
</code></pre>
Here we are using our reactive <code>ResourceRepository</code> to find a resource using the <code>id</code> coming in from the request. Since we're looking for a unique ID, the expected result is either 1 record (the resource with the passed ID is found), or 0 records (there are no records in the database), hence <code>Mono</code> is used as a return type.
Since <code>findAll()</code> can return more that one resource element (if present), <code>Flux</code> is used as the return type.
<h2 id="webfluxwebclient">WebFlux Web Client</h2>
Now that we have a basic REST application set up, let's create a Spring WebFlux client which can send requests to the a WebFlux REST application.
To start a web client we need to create a <code>WebClient</code> object using the server URL:
<pre><code class="hljs">public WebClient openConnection(String url) {
 client = WebClient.create(url);
 return client;
}
</code></pre>
Once the <code>WebClient</code> object is created, we can use it to make requests to the web server.
Let's make a request to the server, retrieving a resource with the given ID:
<pre><code class="hljs">public void getResourceById(String id) {
 Mono&lt;Resource&gt; result = client.get()
 .uri(&quot;/resource/{id}&quot;, &quot;1&quot;)
 .retrieve()
 .bodyToMono(Resource.class);

 result.subscribe(System.out::println);
}
</code></pre>
The <code>bodyToMono()</code> method is responsible for packing the body of the response into a <code>Mono</code>.
Similarly, if the calling endpoint returns data as <code>Flux</code> then we can retrieve it using the following method:
<pre><code class="hljs">public void getAllResources() {
 Flux&lt;Resource&gt; result = client.get()
 .uri(&quot;/resource&quot;)
 .retrieve()
 .bodyToFlux(Resource.class);

 result.subscribe(System.out::println);
}
</code></pre>
<h2 id="conclusion">Conclusion</h2>
The Spring Framework allows developers to make reactive, non-blocking applications and APIs using the Spring's WebFlux stack. WebFlux offers annotations very similar to the ones used in classic Spring MVC applications which makes it easier for the developers to transition to reactive code.
In this guide, we've gone over the most important concepts of the WebFlux framework and built a demo application to show them in practice.
The source code can be found on <a rel="nofollow noopener" target="_blank" href="https://github.com/TaimoorChoudhary/spring-webflux">GitHub</a>.

Taimoor Choudhary

Spring WebFlux is Spring's response to the rising issue of blocking I/O architecture and allows developers to build high-performance reactive applications in Spring in a familiar environment.