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.

Reactive Programming with Spring 5 WebFlux

<h2 id="introduction">Introduction</h2>
The Java Collections Framework is a fundamental and essential framework that any strong Java developer should know like the back of their hand.
A Collection in Java is defined as a group or collection of individual objects that act as a single object.
There are many collection classes in Java and all of them extend the <code>java.util.Collection</code> and <code>java.util.Map</code> interfaces. These classes mostly offer different ways to formulate a collection of objects within a single one.
Java Collections is a framework that provides numerous operations over a collection - searching, sorting, insertion, manipulation, deletion, etc.
This is the fourth and final part of a series of articles on Java Collections:
<ul>
<li><a target="_blank" href="/java-collections-the-list-interface/">The List Interface</a></li>
<li><a target="_blank" href="/java-collections-the-set-interface/">The Set Interface</a></li>
<li><a target="_blank" href="/java-collections-the-map-interface/">The Map Interface</a></li>
<li>Queues, Deques, Stacks (you are here)</li>
</ul>
<h2 id="queue">Queue</h2>
Let's start this final article of the series with the <code>java.util.Queue</code> interface.
<h3 id="principle">Principle</h3>
First of all, what's it good for? The <code>Queue</code> is designed to <a rel="nofollow noopener" target="_blank" href="https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Queue.html">hold elements prior to their processing</a>. Some can be of a fixed capacity, meaning they can contain only up to a certain number of elements.
So, the idea is to push some elements into a <code>Queue</code>, and then retrieve them afterwards. Generally, queues are returning elements respecting the First-In First-Out (FIFO) pattern, meaning the oldest element of the queue is returned first, then the oldest after that, etc.
<blockquote>
You can think of FIFO as a line in front of a store. The first one to stand in the line is the first one to enter.
</blockquote>
But there can be other implementations which respect the Last-In First-Out (LIFO) pattern, or even answer to some kind of priority system (e.g. using <code>Comparator</code>).
<blockquote>
You can think of LIFO as a stack of coins. The last one to be put on the top of the stack is the first one to be taken off.
</blockquote>
Let's now explore the features of the <code>Queue</code> interface!
<h3 id="addinganelement">Adding an Element</h3>
We'll begin by adding an element to a <code>Queue</code>. First, let's instantiate one using the <code>ArrayDeque</code> implementation, which also implements the <code>Deque</code> interface we'll cover later:
<pre><code class="hljs">Queue&lt;Integer&gt; queue = new ArrayDeque&lt;&gt;();
</code></pre>
In order to add an element in this <code>Queue</code>, we have two possibilities: the <code>add()</code> method or the <code>offer()</code> method.
Let's start with the former:
<pre><code class="hljs">queue.add(3);
</code></pre>
And with the latter:
<pre><code class="hljs">queue.offer(4);
</code></pre>
Both return a <code>boolean</code> value indicating if the element was added to the <code>Queue</code> or not, according to its capacity (if it applies). What's the difference between both methods then?
Well, the first will in fact never return <code>false</code>, rather throwing an <code>Exception</code> when adding an element to a full <code>Queue</code>. On the other hand, the second one will return <code>false</code> in such cases.
Instead of <code>ArrayDeque</code>, which is unbounded, let's use the <code>LinkedBlockingQueue</code> which can be assigned a capacity:
<pre><code class="hljs">Queue&lt;Integer&gt; queue = new LinkedBlockingQueue&lt;&gt;(1);
</code></pre>
Here, we've instantiated a queue which can hold a maximum of one element at a time. Therefore, we can't use the <code>add()</code> method two times consecutively without having an exception:
<pre><code class="hljs">queue.add(3);
queue.add(4);
</code></pre>
Trying to add these two elements will result in:
<pre><code class="hljs">java.lang.IllegalStateException: Queue full
 at java.base/java.util.AbstractQueue.add(AbstractQueue.java:98)
</code></pre>
On the other hand, using the <code>offer()</code> method instead will do nothing and return <code>false</code> as a result.
<h3 id="retrievinganelement">Retrieving an Element</h3>
As stated earlier, a <code>Queue</code> generally respects FIFO, which means that it'll return the first entered element first, if we're retrieving one.
The interface offers a few methods to retrieve elements. Two of them, <code>remove()</code> and <code>poll()</code>, remove the element before returning it. The two others, <code>element()</code> and <code>peek()</code> just return it but don't remove it.
The <code>remove()</code> and <code>element()</code> methods will throw an exception when called on an empty <code>Queue</code>:
<pre><code class="hljs">Queue&lt;Integer&gt; queue = new ArrayDeque&lt;&gt;();
queue.offer(3);
queue.offer(4);

queue.poll();
queue.peek();
</code></pre>
Here, our we'll gather the elements <code>3</code> and <code>4</code>, but the first time the element will be removed (via <code>poll()</code>), and the second time not (via <code>peek()</code>), leaving our queue with element <code>4</code> in it.
Using <code>remove()</code> and <code>element()</code> instead of <code>poll()</code> and <code>peek()</code>, respectively, would've had the same results, as the queue is never empty in our case.
<h3 id="iteratingoverelements">Iterating over Elements</h3>
Besides indexed <code>while</code> and <code>for</code> loops, the <code>Queue</code> interface implements <code>Iterable</code> and provides an <code>Iterator</code>, therefore making it eligible for the <code>for-each</code> loop:
<pre><code class="hljs">for (Integer element: queue) {
 System.out.println(element);
}
</code></pre>
That loop would print each element of the queue to the console.
Since Java 8, of course, there's the possibility to call the <code>forEach()</code> method, passing a <a target="_blank" href="/method-references-in-java-8">Method Reference</a>:
<pre><code class="hljs">queue.forEach(System.out::println);
</code></pre>
This achieves the same result as the previous loop.
If you'd like to read more about the <a target="_blank" href="/java-iterable-interface-iterator-listiterator-and-spliterator/">Iterable Interface in Java</a>, we've got you covered!
<h3 id="implementations">Implementations</h3>
Now, what are the classes that implements the <code>Queue</code> interface? There are several implementations of the interface, though these are really the most relevant ones:
<ul>
<li><code>LinkedList</code>: Although mainly known to be a <code>List</code> implementation, this class also implements the <code>Queue</code> interface. This implementation works by linking its elements together and going through that chain when iterating or searching for elements.</li>
<li><code>ArrayDeque</code>: An implementation of both <code>Queue</code> and <code>Deque</code>. Its backed up by an array, which can be increased when the number of elements increase over its current capacity.</li>
<li><code>DelayQueue</code>: Can only contain elements which implement the <code>Delayed</code> interface - elements that become active after a certain time. The <code>DelayQueue</code> will only deliver elements whose delays have expired.</li>
<li><code>PriorityQueue</code>: Orders its elements according to their natural order or a <code>Comparator</code> (if provided). This means it doesn't work using the FIFO principle, but rather returns the element with the highest priority (defined by how they compare to each other).</li>
</ul>
Let's imagine an anomaly system, with an <code>enum</code> defining their severity:
<pre><code class="hljs">public class Anomaly implements Comparable&lt;Anomaly&gt; {
 private String log;
 private Severity severity;

 public Anomaly(String log, Severity severity) {
 this.log = log;
 this.severity = severity;
 }

 @Override
 public int compareTo(Anomaly o) {
 return severity.compareTo(o.severity);
 }

 private enum Severity {
 HIGH,
 MEDIUM,
 LOW
 }
}
</code></pre>
Here, anomalies are naturally ordered by their severities (as <code>enum</code> are naturally ordered by their declaration order).
So, if we were to add two anomalies to a <code>PriorityQueue</code> without a <code>Comparator</code>, one <code>LOW</code> and one <code>HIGH</code>, then the <code>poll()</code> method would return the second anomaly first rather and the first one:
<pre><code class="hljs">Queue&lt;Anomaly&gt; anomalies = new PriorityQueue&lt;&gt;();

Anomaly optionalInformationNotRetrievedAnomaly = new Anomaly(&quot;Couldn&#x27;t retrieve optional information&quot;, Anomaly.Severity.LOW);
anomalies.offer(optionalInformationNotRetrievedAnomaly);

Anomaly databaseNotReachableAnomaly = new Anomaly(&quot;Couldn&#x27;t contact database&quot;, Anomaly.Severity.HIGH);
anomalies.offer(databaseNotReachableAnomaly);

anomalies.poll(); // This would return &#x27;databaseNotReachableAnomaly&#x27;
</code></pre>
Now, if we pass a <code>Comparator</code> to the <code>PriorityQueue</code> constructor, let's say one that reverses the natural order:
<pre><code class="hljs">Queue&lt;Anomaly&gt; anomalies = new PriorityQueue&lt;&gt;(Comparator.reverseOrder());
</code></pre>
Then in the same scenario as before, the <code>poll()</code> method would return the first anomaly - that is <code>optionalInformationNotRetrievedAnomaly</code>.
<h2 id="deque">Deque</h2>
Now that the <code>Queue</code> interface has been covered, let's jump to <code>Deque</code>.
<h3 id="principle">Principle</h3>
Deque stands for <a rel="nofollow noopener" target="_blank" href="https://en.wikipedia.org/wiki/Double-ended_queue">Double Ended Queue</a>, which means this is a queue that can be accessed by both ends, and therefore can be used with both FIFO and LIFO styles. By default, it organizes its element LIFO style, meaning that getting the first in the <code>Deque</code> would return the last that had been added.
<h3 id="addinganelement">Adding an Element</h3>
Let's jump to <code>Deque</code> usages with element insertion. There are multiple possibilities to achieve that:
<ul>
<li>Some methods add the element at the top, some at the bottom</li>
<li>Some methods throw an exception if the <code>Deque</code> is full, some don't</li>
</ul>
Let's summarize them in a table:
<table class="table table-striped" style="white-space:nowrap;">
 <tr>
 <th></th>
 <th>Top</th>
 <th>Bottom</th>
 </tr>
 <tr>
 <td>No Exception</td>
 <td><code>offerFirst()</code></td>
 <td><code>offer()</code>, <code>offerLast()</code></td>
 </tr>
 <tr>
 <td>Exception</td>
 <td><code>addFirst()</code>, <code>push()</code></td>
 <td><code>add()</code>, <code>addLast()</code></td>
 </tr>
</table>
Let's say we have a <code>Deque</code> of <code>Integer</code> and we call <code>addFirst()</code> with integers <code>3</code> and <code>4</code>:
<pre><code class="hljs">Deque&lt;Integer&gt; deque = new ArrayDeque&lt;&gt;();
deque.addFirst(3);
deque.addFirst(4);
</code></pre>
Then, the deque will contain <code>4</code> and <code>3</code>, in this order.
If we had used <code>addLast()</code>, then it would've contained <code>3</code> and <code>4</code>, in this order. The same would've happened with <code>offerFirst()</code> and <code>offerLast()</code>, respectively.
<h3 id="retrievingandremovinganelement">Retrieving and Removing an Element</h3>
Now, let's see how to retrieve elements from a <code>Deque</code>. Again, there are multiple possibilities:
<ul>
<li>Some methods return the first element, some return the last</li>
<li>Some methods remove the element when returned, some don't</li>
<li>Some methods throw an exception if the <code>Deque</code> is empty, some don't</li>
</ul>
To make it a bit easier, we're going to summarize that in a table as well:
<table class="table table-striped" style="white-space:nowrap; overflow-x:auto;">
 <tr>
 <th></th>
 <th>First (top) element, no removal</th>
 <th>First (top) element, removal</th>
 </tr>
 <tr>
 <td>No Exception</td>
 <td><code>peek()</code>, <code>peekFirst()</code></td>
 <td><code>poll()</code>, <code>pollFirst()</code></td>
 </tr>
 <tr>
 <td>Exception</td>
 <td><code>getFirst()</code>, <code>element()</code></td>
 <td><code>remove()</code>, <code>removeFirst()</code>, <code>pop()</code></td>
 </tr>
</table>
<table class="table table-striped" style="white-space:nowrap;overflow-x:auto;">
 <tr>
 <th></th>
 <th>Last (bottom) element, no removal</th>
 <th>Last (bottom) element, removal</th>
 </tr>
 <tr>
 <td>No Exception</td>
 <td><code>peekLast()</code></td>
 <td><code>pollLast()</code></td>
 </tr>
 <tr>
 <td>Exception</td>
 <td><code>getLast()</code></td>
 <td><code>removeLast()</code></td>
 </tr>
</table>
Let's say we have a <code>Deque</code> of <code>Integer</code> with elements <code>4</code> and <code>3</code>, top to bottom. And we call <code>peekFirst()</code>:
<pre><code class="hljs">Deque&lt;Integer&gt; deque = new ArrayDeque&lt;&gt;();
deque.push(3);
deque.push(4);

deque.peekFirst();
</code></pre>
Then, this would return <code>4</code>, without removing the element. If we had used <code>peekLast()</code>, then it would've returned <code>3</code>.
Now, if we were to use <code>removeFirst()</code> or <code>pop()</code>, we would got <code>4</code> but the <code>Deque</code> would only contain <code>3</code> in the end.
<h3 id="iteratingoverelements">Iterating over Elements</h3>
As for the <code>Queue</code>, we can iterate using the standard mechanisms and the <code>forEach()</code> method. We just have to remember that, by default, the <code>Deque</code> organizes its elements LIFO style and therefore will iterate on them, top to bottom:
<pre><code class="hljs">Deque&lt;Integer&gt; deque = new ArrayDeque&lt;&gt;();
deque.push(3);
deque.push(4);

deque.forEach(System.out::println);
</code></pre>
This would print:
<pre><code class="hljs">4
3
</code></pre>
You could also use an <code>Iterator</code>:
<pre><code class="hljs">Deque&lt;Integer&gt; deque = new ArrayDeque&lt;&gt;();
deque.push(3);
deque.push(4);

for (Iterator&lt;Integer&gt; iterator = deque.iterator(); iterator.hasNext();) {
 System.out.println(iterator.next());
}
</code></pre>
This would also print:
<pre><code class="hljs">4
3
</code></pre>
<h3 id="implementations">Implementations</h3>
<ul>
<li><code>ArrayDeque</code>: This is the one we used for <code>Queue</code> and which is backed up by an <code>array</code>. Implements both <code>Queue</code> and <code>Deque</code>.</li>
<li><code>LinkedList</code>: Implements both <code>Queue</code>, <code>Deque</code> and <code>List</code>. We also see this one earlier.</li>
<li><code>LinkedBlockingDeque</code>: This one works a bit like the <code>LinkedList</code>, but can be bounded. Thus the insertion operations we saw earlier would throw an exception if this <code>Deque</code> was full.</li>
</ul>
<h2 id="stack">Stack?</h2>
It's worth noting that a <code>Stack</code> exists as well. It was introduced in the beginning of Java and was to be used as a LIFO collection, with <code>push()</code> and <code>pop()</code> methods.
<blockquote>
Why not use it then?
</blockquote>
Because the documentation advise us to use the <code>Deque</code> interface which offers a more consistent API. Plus, <code>Stack</code> is subclass of <code>Vector</code> and thus is tightly bound to it, making it a <code>List</code> above all things, which is conceptually different from a stack.
<h2 id="conclusion">Conclusion</h2>
The Java Collections Framework is a fundamental framework that every Java developer should know how to use.
In this article, we've talked about the <code>Queue</code> and <code>Deque</code> interfaces and covered their main operations. The full code for this article can be found over on <a rel="nofollow noopener" target="_blank" href="https://github.com/dupirefr/stackabuse-code">GitHub</a>.

François Dupire

The Java Collections Framework is a fundamental and essential framework. The Queues and Deques are designed to hold elements prior to processing in FIFO or LIFO styles.

Java Collections: Queue and Deque Interfaces

Guest Contributor

AWS SNS is a publisher/subscriber messaging system and a popular choice for many developers. In this tutorial, we'll be making a Spring Cloud app with SMS and Email messaging support.

Spring Cloud: AWS SNS

Usman Malik

BERT is a text representation technique similar to Word Embeddings. In this article, we'll be using BERT and TensorFlow 2.0 for text classification.