Robley Gori

AWS SQS allows us to decouple large systems by providing them with a loosely-coupled communication mechanism. In this article, we'll be using Node.js and AWS SQS to build a messaging system, ideal for microservices.

Message Queueing in Node.js with AWS SQS

Janith Kasun

Proxies have the ability to change the fundamental behavior of objects and functions.
In this article, we'll talk about JavaScript proxies, introduced in ES6 and showcase their functionality.

Introduction to JavaScript Proxies in ES6

Josh Simpson

There are many cloud-based hosting services online. In this article, we'll build a Node.js application, dockerize it and deploy it to a DigitalOcean Droplet to get it up and running online.

Deploying a Node.js App to a DigitalOcean Droplet with Docker

Vladimir Batoćanin

PyOpenGL is a standardized bridge between OpenGL and Python. PyGame is a standardized library for making games with Python. In this article, we'll leverage the two and cover some important topics in OpenGL with Python.

Advanced OpenGL in Python with PyGame and PyOpenGL

<h2 id="introduction">Introduction</h2>
Scheduling tasks to be performed at a later date, or repeated in a fixed interval, is a very useful feature. For example, newsletter systems or tasks which process information at a set time-frame rely on being scheduled to run at certain time points.
Since Spring Boot offers several options, we're going to cover and implement all of them.
<h2 id="projectsetup">Project Setup</h2>
As usual, when it comes to building Spring Boot applications, making a skeleton project is easiest with the help of <a rel="nofollow noopener" target="_blank" href="https://start.spring.io/">Spring Initializr</a>. You don't need any additional dependencies to enable scheduling.
To enable scheduling, all we have to do is annotate our main class:
<pre><code class="hljs">@SpringBootApplication
@EnableScheduling
public class SampleScheduleApplication {
 public static void main(String[] args) {
 SpringApplication.run(SampleScheduleApplication.class, args);
 }
}
</code></pre>
The <code>@EnableScheduling</code> annotation allows the Spring container to notice any <code>@Scheduled</code> annotations in Spring-managed beans.
<h3 id="conditionalscheduling">Conditional Scheduling</h3>
There's another way to enable scheduling - by using the <code>@ConditionalOnProperty</code> annotation. It allows us to &quot;switch on&quot; and &quot;switch off&quot; our configuration classes by setting a property in the <code>application.properties</code> class.
To do this, let's make a new class and annotate it with both the <code>@EnableScheduling</code>, <code>@Configuration</code> and <code>@ConditionalOnProperty</code> annotations:
<pre><code class="hljs">@EnableScheduling
@Configuration
@ConditionalOnProperty(name = &quot;spring.enable.scheduling&quot;)
public class ScheduleEnabling {}
</code></pre>
Now, in the <code>application.properties</code> file, let's add our new property and set it to <code>true</code>:
<pre><code class="hljs">spring.enable.scheduling = true
</code></pre>
Just by shifting this variable, we can turn the functionality on and off.
To execute a method on a schedule, you need to annotate it with the <code>@Scheduled</code> annotation. Changing the parameters of the annotation will define if it's at a fixed rate, with a fixed delay, custom intervals, etc.
<h4 id="schedulingwithfixedrateandfixedratestring">Scheduling with fixedRate and fixedRateString</h4>
To schedule a method to execute on a fixed rate, we'll add the adequate parameter to our annotation - <code>@Scheduled(fixedRate)</code>. This parameter accepts integers, expressed in milliseconds. So if you want a rate of 1 second, the rate should be entered as <code>1000</code> since the value is milliseconds.
Alternatively, you can use the <code>@Scheduled(fixedRateString)</code> parameter to externalize the amount by using an environment string variable.
To avoid confusion, we'll go with the <code>fixedRateString</code>, which is essentially a string parameter that specifies the rate, instead of the integer value. It can get a bit tricky trying to make a method recur monthly in milliseconds.
Let's set a variable in the <code>application.properties</code> file:
<pre><code class="hljs">sample.schedule.string = PT2S
</code></pre>
The prefix <code>PT</code> is the ISO-8601 standard for <a rel="nofollow noopener" target="_blank" href="https://en.wikipedia.org/wiki/ISO_8601#Durations">notating durations or periods</a>, and with this, we can call the <code>sample.schedule.string</code> to schedule a method call in 2 seconds.
This also allows us to specify different delays for different profiles in use:
<pre><code class="hljs">@Scheduled(fixedRateString = &quot;${sample.schedule.string}&quot;)
public void scheduleTaskWithFixedRate() throws InterruptedException {
 task1();
 task2();
}

public void task1() throws InterruptedException {
 logger.info(&quot;Task 1 starts&quot; + Thread.currentThread());
 Thread.sleep(1000);
 logger.info(&quot;Task 1 ends&quot; + Thread.currentThread());
}

public void task2() throws InterruptedException {
 logger.info(&quot;Task 2 starts&quot; + Thread.currentThread());
 Thread.sleep(1000);
 logger.info(&quot;Task 2 ends&quot; + Thread.currentThread());
}
</code></pre>
Let's run this piece of code:
<img src="https://stackabuse.s3.amazonaws.com/media/scheduling-spring-boot-tasks-1.PNG" alt="Scheduling with Fixed Rate">
However, we can see a problem here:
<blockquote>
Task 1 starts at 00:01:44 and ends at 00:01:45, as expected. 
Task 2 starts at 00:01:45 and ends at 00:01:46, as expected. 
Task 1 starts at 00:01:46 and ends at 00:01:47.
</blockquote>
Since both <code>task1()</code> and <code>task2()</code> have been executed, you'd expect the method to wait for an additional 2 seconds to run again.
Fixed rate tasks don't wait for the completion of the previous execution, it simply invokes the method at a specific rate. Since it takes 2 seconds to finish methods <code>task1()</code> and <code>task2()</code>, the method is invoked again at the same time these two finish.
This can become a problem in an environment with multiple scheduled tasks in place.
Consider this - <code>task1()</code> takes 1 minute to complete, and <code>task2()</code> takes 5 seconds to complete. Since both of them are running on a single thread, there might be a situation that <code>task1()</code> starts processing and will lock the thread. This won't allow <code>task2()</code> to process even if there is a <code>fixedRate</code> of 5 seconds.
In this scenario, we need to increase the number of threads that are available in our thread pool for scheduling. Spring provides a property that we can manipulate to specify the size: <code>spring.task.scheduling.pool.size</code> - the default value is 1.
We may use fixed rate when a particular task needs to be done repeatedly but each task is independent of the other. Also, be careful not to have heavy tasks without a proper rate, since incompletion may lead to a nasty <code>OutOfMemoryError</code>.
<h4 id="schedulingwithfixeddelayandfixeddelaystring">Scheduling with fixedDelay and fixedDelayString</h4>
A <code>fixedDelay</code> works very similar to a <code>fixedRate</code>. But the difference here is that the fixed delay waits until the completion of the previous execution to start the next one. Imagine a scenario where your function takes 1 second to complete execution and you've given a fixed delay of 2 seconds.
This, in turn, will result in a total of 3 seconds.
In the logs below, you can clearly see that the difference between the two subsequent tasks is 3 seconds. This includes the fixed delay time of 1 second as well as the 2 seconds that we've given as sleep:
<pre><code class="hljs">@Scheduled(fixedDelayString = &quot;${sample.schedule.string}&quot;)
public void scheduleTaskWithFixedDelay() throws InterruptedException {
 task1();
}

public void task1() throws InterruptedException {
 logger.info(&quot;Task 1 starts&quot; + Thread.currentThread());
 Thread.sleep(1000);
 logger.info(&quot;Task 1 ends&quot; + Thread.currentThread());
}
</code></pre>
Let's run this piece of code:
<img src="https://stackabuse.s3.amazonaws.com/media/scheduling-spring-boot-tasks-2.PNG" alt="Scheduling with Fixed Delay">
There's an additional parameter that can be added to scheduled tasks, and that is the <code>initialDelay</code>.
This one doesn't require much explanation as it is used in conjunction with the above two. Initial delay, as the name rightfully suggests, provides the initial delay for the first execution.
If you have a function with an initial delay of 2 seconds and a fixed rate of 1 second, then the first execution will be delayed by 2 seconds and the function will run every 1 second afterward:
<pre><code class="hljs">@Scheduled(initialDelay = 1000, fixedRateString = &quot;${sample.schedule.string}&quot;)
public void scheduleTaskWithInitialDelay() throws InterruptedException {
 task1();
}
</code></pre>
We can also opt to use an <code>initialDelayString</code> that allows us to externalize the delay value.
<h3 id="customtimeintervals">Custom Time Intervals</h3>
Fixed rate and fixed delay are the most commonly used parameters for scheduling and the delay strings allow us to externalize the values and make them configurable.
But till now we've seen only very generic examples for the rates. There might be a situation where we need very specific time intervals. Behold, custom <code>cron</code> expressions.
<h4 id="cronexpressions">Cron Expressions</h4>
Most developers have probably heard about the <a rel="nofollow noopener" target="_blank" href="https://en.wikipedia.org/wiki/Cron">cron</a> utility in Linux. It is a daemon process which runs without the need for user intervention and executes tasks.
The syntax for cron expressions in the <code>cron</code> utility and the syntax for cron expressions for scheduling are mostly similar.
Cron expressions are basically strings that describe the details of the schedule. It provides much more control than the previous 2 methods:
<table class="table table-striped" style="white-space:nowrap; font-size:15px;">
 <tr>
 <th>Name</th>
 <th>Required</th>
 <th>Allowed Values</th>
 <th>Allowed Special Characters</th>
 </tr>
 <tr>
 <td>Seconds</td>
 <td>Yes</td>
 <td>0-59</td>
 <td><code>, - * /</code></td>
 </tr>
 <tr>
 <td>Minutes</td>
 <td>Yes</td>
 <td>0-59</td>
 <td><code>, - * /</code></td>
 </tr>
 <tr>
 <td>Hours</td>
 <td>Yes</td>
 <td>0-23</td>
 <td><code>, - * /</code></td>
 </tr>
 <tr>
 <td>Day of Month</td>
 <td>Yes</td>
 <td>1-31</td>
 <td><code>, - * / L W C</code></td>
 </tr>
 <tr>
 <td>Month</td>
 <td>Yes</td>
 <td>0-11 or JAN-DEC</td>
 <td><code>, - * /</code></td>
 </tr>
 <tr>
 <td>Day of Week</td>
 <td>Yes</td>
 <td>1-7 or SUN-SAT</td>
 <td><code>, - * / L C #</code></td>
 </tr>
 <tr>
 <td>Year</td>
 <td>No</td>
 <td>empty or 1970-2099</td>
 <td><code>, - * /</code></td>
 </tr>
</table>
The table above specifies the required values, allowed values, and special characters for a cron expression.
Cron expressions can be very simple, but also very complex. A clear understanding of the values will make it easier to play around with them.
Except for the year field, all the other fields are mandatory:
<pre><code class="hljs">&lt;second&gt; &lt;minute&gt; &lt;hour&gt; &lt;day-of-month&gt; &lt;month&gt; &lt;day-of-week&gt; &lt;year&gt;
</code></pre>
Example: <code>0 0 12 * * ? 2019</code> – This cron expression fires at 12 PM, every day of the month, for every month, for the year 2019.
For some common values, you can also use the predefined annotations:
<ul>
<li><code>@reboot</code>: Schedule the method for every reboot of the application</li>
<li><code>@yearly</code>/<code>@anually</code>: Schedule the method to run once a year</li>
<li><code>@monthly</code>: Schedule the method to run once a month</li>
<li><code>@weekly</code>: Schedule the method to run once a week</li>
<li><code>@daily</code>/<code>@midnight</code>: Schedule the method to run once a day</li>
<li><code>@hourly</code>: Schedule the method to run once every hour</li>
</ul>
Let's write a code example for this:
<pre><code class="hljs">@Scheduled(cron=&quot;0 0 12 * * ? 2019&quot;)
public void doSomething() {
 // Something
}
</code></pre>
An important thing to note when scheduling are time zones - the bane of every developer who works with time.
You'll likely wish to set the <code>zone</code> flag to a specific region. For an example, we'll run this method at 12PM, every day in 2019, based on Paris' time zone:
<pre><code class="hljs">@Scheduled(cron=&quot;0 0 12 * * ? 2019&quot;, zone=&quot;Europe/Paris&quot;)
public void doSomething() {
 // Something
}
</code></pre>
You can find all of the time zones at the <a rel="nofollow noopener" target="_blank" href="https://docs.oracle.com/cd/B13866_04/webconf.904/b10877/timezone.htm">official Oracle docs</a>.
Of course, you can also externalize cron expressions via the <code>application.properties</code> file:
<pre><code class="hljs">cron.expression= 0 0 12 * * ? 2019
</code></pre>
And then invoke it through:
<pre><code class="hljs">@Scheduled(cron=&quot;${cron.expression}&quot;, zone=&quot;Europe/Paris&quot;)
public void doSomething() {
 // Something
}
</code></pre>
You can also use a site like <a rel="nofollow noopener" target="_blank" href="http://freeformatter.com/cron-expression-generator-quartz.html">FreeFormatter</a> to generate a cron expression by setting the input parameters. This is very helpful for those new to creating cron expressions.
<h3 id="conclusion">Conclusion</h3>
In this article, we've seen how we can schedule tasks with Spring Boot. The biggest advantage of using Spring Boot is the ease with which we can implement scheduling. Not only that, it also offers several options so that we can pick what suits our requirements.
Schedulers are essential components of most applications because they send out time-critical as well as user-specific information as and when needed. Now you know how!

Guest Contributor

Scheduling tasks or repeating them in intervals is often a useful feature. In this article, we'll explore the scheduling capabilities of Spring Boot.

Scheduling Spring Boot Tasks

<h2 id="introduction">Introduction</h2>
In this brief article we'll be going over how to extract information from a POST body in Express.js. The HTTP protocol provides a number of ways to pass information from a client to a server, with POST bodies being the most flexible and most commonly used method to send data via HTTP.
Another way, which is typically used for different use-cases, is to convey information using query strings or URL parameters. For more info, check out how to <a target="_blank" href="/get-query-strings-and-parameters-in-express-js/">get query strings and parameters in Express.js</a>.
For this article I assume you have some experience with Node.js and creating simple <a rel="nofollow noopener" target="_blank" href="http://expressjs.com/">Express.js</a> servers.
<h2 id="sendingpostdatainhttp">Sending POST Data in HTTP</h2>
Data can be sent via an HTTP POST call for many reasons, with some of the most common being via an HTML <code>&lt;form&gt;</code> or an API request. The data can take on a few different forms, with the most common being:
<ul>
<li><code>application/x-www-form-urlencoded</code>: Data in this encoding is formatted like a query string you'd see in a URL, with key-value paris being separated by <code>&amp;</code> characters. For example: <code>foo=bar&amp;abc=123&amp;stack=abuse</code>. This is the default encoding.</li>
<li><code>multipart/form-data</code>: This encoding is typically used for sending files. In short, each key-value is sent in the same request, but different &quot;parts&quot;, which are separated by &quot;boundaries&quot; and include more meta-data.</li>
<li><code>text/plain</code>: This data is just sent as unstructured plain text, and typically is not used.</li>
</ul>
A raw HTTP POST request with the <code>application/x-www-form-urlencoded</code> encoding might look something like this:
<pre><code class="hljs">POST /signup HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 53

username=scott&amp;password=secret&amp;website=stackabuse.com
</code></pre>
<h2 id="extractingpostdata">Extracting POST Data</h2>
Before we can get started accessing POST data right away, we need to properly configure our Express app. This configuration needs to be done since not all web app servers need body parsing, and what body parsing is enabled depends on your application.
To set this up, we'll be using the <a rel="nofollow noopener" target="_blank" href="https://www.npmjs.com/package/body-parser">body-parser</a> package, which can handle many forms of data. This package is a <a rel="nofollow noopener" target="_blank" href="http://expressjs.com/en/guide/writing-middleware.html">middleware</a> that intercepts the raw body and parses it in to a form that your application code can easily use.
<pre><code class="hljs">// index.js
const express = require(&#x27;express&#x27;);
const bodyParser = require(&#x27;body-parser&#x27;);

const app = express();
app.use(bodyParser.urlencoded({ extended: true }));

app.post(&#x27;/post-test&#x27;, (req, res) =&gt; {
 console.log(&#x27;Got body:&#x27;, req.body);
 res.sendStatus(200);
});

app.listen(8080, () =&gt; console.log(`Started server at http://localhost:8080!`));
</code></pre>
Notice how we call <code>app.use(...)</code> before defining our route. The order here matters. This will ensure that the <code>body-parser</code> will run before our route, which ensures that our route can then access the parsed HTTP POST body.
To test this, we'll first start the Express app and then use the <code>curl</code> utility in a different console window:
<pre><code class="hljs">$ curl -d &quot;username=scott&amp;password=secret&amp;website=stackabuse.com&quot; -X POST http://localhost:8080/post-test
OK
</code></pre>
<pre><code class="hljs">$ node index.js
Started server at http://localhost:8080!
Got body: { username: &#x27;scott&#x27;,
 password: &#x27;secret&#x27;,
 website: &#x27;stackabuse.com&#x27; }
</code></pre>
Here you can see that the query string data was parsed in to a JavaScript object that we can easily access.
Another important thing to note is our use of the <code>extended</code> option when calling <code>bodyParser.urlencoded</code>. Using the <code>extended</code> option tells <code>body-parser</code> to use the <code>qs</code> library to parse the URL-encoded data. This allows for things like objects and arrays to be encoded into the URL-encoded format.
And while <code>urlencoded</code> is one of the most commonly used parsers that <code>body-parser</code> provides, you can also use the following:
<ul>
<li><code>.json()</code>: Parses JSON-formatted text for bodies with a <code>Content-Type</code> of <code>application/json</code>.</li>
<li><code>.raw()</code>: Parses HTTP body in to a <code>Buffer</code> for specified custom <code>Content-Type</code>s, although the default accepted <code>Content-Type</code> is <code>application/octet-stream</code>.</li>
<li><code>.text()</code>: Parses HTTP bodies with a <code>Content-Type</code> of <code>text/plain</code>, which returns it as a plain string.</li>
</ul>
Each of these parsers also supports automatic inflation of data encoded with <a rel="nofollow noopener" target="_blank" href="https://en.wikipedia.org/wiki/Gzip">gzip</a> or <a rel="nofollow noopener" target="_blank" href="https://en.wikipedia.org/wiki/DEFLATE">deflate</a>, so compression can still be transparently used without any extra work by your application code.
The great thing about the middleware model and how this package parses data is that you're not stuck to using just one parser. You can enable one or more parsers for your app to ensure that all data types are processed properly:
<pre><code class="hljs">// index.js
const express = require(&#x27;express&#x27;);
const bodyParser = require(&#x27;body-parser&#x27;);

const app = express();
app.use(bodyParser.urlencoded({ extended: true }));
app.use(bodyParser.json());
app.use(bodyParser.raw());

// ...
</code></pre>
So now if we were to send an HTTP POST request with JSON as the body, it will be parsed in to a regular JSON object in the <code>req.body</code> property:
<pre><code class="hljs">POST /post-test HTTP/1.1
Host: localhost:8080
Content-Type: application/json
Content-Length: 69

&#x27;{&quot;username&quot;:&quot;scott&quot;,&quot;password&quot;:&quot;secret&quot;,&quot;website&quot;:&quot;stackabuse.com&quot;}&#x27;
</code></pre>
<pre><code class="hljs">$ node index.js
Started server at http://localhost:8080!
Got body: { username: &#x27;scott&#x27;,
 password: &#x27;secret&#x27;,
 website: &#x27;stackabuse.com&#x27; }
</code></pre>
<h2 id="conclusion">Conclusion</h2>
The most common way to send diverse and large amounts of data via HTTP is to use the POST method. Before we can easily access this data on the server side in Express, we need to use some middleware, like the <code>body-parser</code> package, to parse the data in to a format that we can easily access. Once the data from the raw HTTP request is parsed, it can then be accessed via the <code>body</code> property of the <code>req</code> object.
In this article we explained a bit about the various content types/encodings, how to use the <code>body-parser</code> package and its various options, and how to access the parsed data. If you see any issues or have suggestions, feel free to leave a comment below.

Scott Robinson

In this brief article, we'll explore how to extract information from a POST request body in Express.js and Node.js

Get HTTP POST Body in Express.js

<h2 id="overview">Overview</h2>
In this article, we'll look into <a rel="nofollow noopener" target="_blank" href="https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html">Spring Boot Actuator</a>, which provides built-in production ready endpoints that can be used for monitoring and controlling your application.
Monitoring applications may include something as simple as knowing the Health and Info to some complex data like understanding Traffic and Metrics for our application. For example, how much resources (CPU, RAM, etc.) are being used by the application.
You can choose to interact with actuators either with HTTP endpoints or with JMX beans. In this tutorial, we would be using the HTTP endpoints.
In Spring Boot 1, the actuator could only be used with Spring MVC. But with Spring Boot 2 and the introduction of <a rel="nofollow noopener" target="_blank" href="https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html">WebFlux</a>, its support has been extended and can also be used with the <a rel="nofollow noopener" target="_blank" href="https://eclipse-ee4j.github.io/jersey/">Jersey</a> framework without the need of Spring MVC in the classpath.
<h2 id="springbootactuator">Spring Boot Actuator</h2>
In order to demonstrate the actuator in work, we'll be using a simple Spring REST-based service, running on the default port (<code>8080</code>) with a single endpoint of <code>/hello</code> that returns a String message.
To add actuator, we simply add the dependency to our <code>pom.xml</code> file:
<pre><code class="hljs">&lt;dependency&gt;
 &lt;groupId&gt;org.springframework.boot&lt;/groupId&gt;
 &lt;artifactId&gt;spring-boot-starter-actuator&lt;/artifactId&gt;
 &lt;version&gt;${VERSION}&lt;/version&gt;
&lt;/dependency&gt;
</code></pre>
All the endpoints fall under a common prefix of <code>/actuator</code>. To check, let's navigate our browser to <code>http://localhost:8080/actuator</code>:
<img src="https://stackabuse.s3.amazonaws.com/media/spring-boot-actuator-1.png" alt="spring boot actuator default endpoints">
Note: In Spring Boot 1, all of the actuator endpoints were in the root base path, i.e <code>/</code>, but in Spring Boot 2, all of them are by default grouped under <code>/actuator</code>.
You can change the base path of the actuator endpoints by adding the following properties in the <code>application.properties</code>:
<pre><code class="hljs">management.endpoints.web.base-path=/admin
management.server.port=8090
</code></pre>
Now, all the actuator endpoints will be under the <code>/admin</code> prefix, which makes sense since only an admin should have access to metrics such as these. For this tutorial, we are going to leave it under the default <code>/actuator</code>.
By default, management endpoints are available on the same port as that of your application, but you may choose to expose these on a different HTTP port by setting the <code>management.server.port</code> to an HTTP port of your choice.
We will not be changing it as the default behavior is preferable especially if you are running on the cloud.
<h2 id="actuatorendpoints">Actuator Endpoints</h2>
A full list of available endpoints can be seen in the <a rel="nofollow noopener" target="_blank" href="https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html#production-ready-endpoints">official documentation</a>. You may have noticed that although there are many endpoints available, the result of <code>http://localhost:8080/actuator</code> shows only <code>/health</code> and <code>/info</code>.
Since actuator endpoints contain sensitive information, we have had to explicitly expose each of them, otherwise, we'll only be able to see rudimentary information that's already apparent.
Navigate our browser to <code>http://localhost:8080/actuator/health</code>:
<img src="https://stackabuse.s3.amazonaws.com/media/spring-boot-actuator-2.png" alt="spring boot actuator health">
Now, let us check the <code>/info</code> similarly and you will notice that it returns an empty response.
This is because we have not provided any information about it to Spring. This can be done by adding properties to the <code>info</code> prefix in the <code>application.properties</code>:
<pre><code class="hljs">info.name= Test Spring Service
info.more.detail= This is a demo for Spring Actuator
</code></pre>
<img src="https://stackabuse.s3.amazonaws.com/media/spring-boot-actuator-3.png" alt="spring boot actuator info">
You can structure the JSON key according to your needs.
<h3 id="exposingendpoints">Exposing Endpoints</h3>
In order to expose endpoints, Spring provides 2 properties that we can use individually or in combination:
<ul>
<li><code>management.endpoints.web.exposure.exclude</code>: Used to exclude a list of endpoints that we do not want to expose. The default value for it is empty.</li>
<li><code>management.endpoints.web.exposure.include</code>: Used to include a list of endpoints that we want to expose. The default value for it is <code>info, health</code>. This is why both these endpoints were available by default.</li>
</ul>
Note: <code>exclude</code> takes precedence over <code>include</code>
So, let's tweak the configuration so that we want to expose all of the endpoints except for <code>info</code> and <code>health</code>:
<pre><code class="hljs">management.endpoints.web.exposure.include=*
management.endpoints.web.exposure.exclude=info,health
</code></pre>
Note: If you are using a YAML-based properties file, <code>*</code> has a special meaning and can only be used with quotes:
<pre><code class="hljs">management:
 endpoints:
 web:
 exposure:
 exclude: &quot;*&quot;
</code></pre>
For this tutorial, we will be exposing all of our actuator endpoints. So let's add the following endpoint in our <code>application.properties</code>:
<pre><code class="hljs">management.endpoints.web.exposure.include= *
</code></pre>
Now, let's check the actuator endpoint again by opening <code>http://localhost:8080/actuator</code>:
<img src="https://stackabuse.s3.amazonaws.com/media/spring-boot-actuator-4.png" alt="spring boot actuator all">
<h3 id="enablingendpoints">Enabling Endpoints</h3>
Besides exposing endpoints, we can also enable and disable them. While exposing only regulates whether we can see them or not, enabling regulates whether they exist as a bean in the context of Spring.
By default, all the endpoints are enabled except for one, the <code>shutdown</code> endpoint. You can enable/disable each endpoint by setting the <code>management.endpoint.&lt;id&gt;.enabled</code> property:
<pre><code class="hljs">management.endpoint.shutdown.enabled=true
management.endpoint.beans.enabled=false
</code></pre>
You can also disable all endpoints by setting <code>management.endpoints.enabled-by-default</code> to <code>false</code> and then individually enable the properties you want. For this tutorial, we would be going with the default setting.
Note: Disabling the endpoints will remove them as beans from the context completely and it wouldn't matter if you have exposed them.
<h3 id="cachingsupport">Caching Support</h3>
All the endpoints (that are READ operation and do not take any parameter) have basic caching support as well.
Every endpoint has a property of <code>cache.time-to-live</code> that's automatically generated for you which can be used to specify the cache time:
<pre><code class="hljs">management.endpoint.beans.cache.time-to-live=10s
</code></pre>
<h2 id="securingactuatorendpoints">Securing Actuator Endpoints</h2>
By now, it would have been clear that these endpoints store sensitive information about our application and it would be a good idea to secure them.
To do it we can simply add spring security to our application by adding the <code>spring-boot-starter-security</code> dependency in our <code>pom.xml</code>:
<pre><code class="hljs">&lt;dependency&gt;
 &lt;groupId&gt;org.springframework.boot&lt;/groupId&gt;
 &lt;artifactId&gt;spring-boot-starter-security&lt;/artifactId&gt;
 &lt;version&gt;${VERSION}&lt;/version&gt;
&lt;/dependency&gt;
</code></pre>
By default, just by importing it, all of the endpoints in our application will be secured.
But let's suppose we want our <code>/health</code> endpoint available to all, but the rest of them to be secure. This warrants a custom filter for letting certain users pass and holding back others.
For that we have to add a <code>@Configuration</code> class that extends the <code>WebSecurityConfigurerAdapter</code>, like with any other Spring Boot application that we want to secure with Spring Security.
Then we need to override the <code>.configure()</code> method where we define the security configuration for our application:
<pre><code class="hljs">@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

 @Override
 protected void configure(HttpSecurity http) throws Exception {
 http.csrf().disable()
 .authorizeRequests()
 .requestMatchers(EndpointRequest.to(HealthEndpoint.class)).permitAll()
 .requestMatchers(EndpointRequest.toAnyEndpoint()).authenticated()
 .and()
 .httpBasic();
 }
}
</code></pre>
The above code is self-explanatory, where we allowed any <code>HealthEndpoint</code> to be publicly available, while others require some basic authentication. Also, note that <code>EndpointRequest.to()</code> is a convenience method that automatically takes care of the final URL of your actuator endpoints because you might have changed the base-path of it in your application.
Let's restart again and check the logs:
<img src="https://stackabuse.s3.amazonaws.com/media/spring-boot-actuator-5.png" alt="spring boot actuator security">
Because Spring Security is in the classpath, it automatically creates a username of <code>user</code> and a password that is randomly generated at the start of the application, as shown in the logs.
Let's check the <code>/health</code> endpoint and you will see the output without any authentication box. Now let's try any other endpoint, say <code>/env</code> and you will be asked to authenticate:
<img src="https://stackabuse.s3.amazonaws.com/media/spring-boot-actuator-6.png" alt="spring boot actuator security authenticate">
Enter the username and password and you can see the appropriate response:
<img src="https://stackabuse.s3.amazonaws.com/media/spring-boot-actuator-7.png" alt="spring boot actuator security authenticate env">
If you want to define your own username and password, you can easily do so via the <code>application.properties</code>:
<pre><code class="hljs">spring.security.user.name=user
spring.security.user.password=password
</code></pre>
<h2 id="creatingcustomendpoints">Creating Custom Endpoints</h2>
This can be achieved by adding the <code>@Endpoint</code> and <code>@Component</code> annotation to your class. After that, you can create methods and annotate them with <code>@ReadOperation</code>, <code>@WriteOperation</code>, or <code>@DeleteOperation</code> accordingly. You can, of course, have multiple methods with different operations.
The idea of having multiple operations is to map to different HTTP request methods:
<ul>
<li><code>@ReadOperation</code> maps to HTTP GET</li>
<li><code>@WriteOperation</code> maps to HTTP POST</li>
<li><code>@DeleteOperation</code> maps to HTTP DELETE</li>
</ul>
Let's create a simple custom endpoint:
<pre><code class="hljs">@Component
@Endpoint(id = &quot;details&quot;)
public class DetailsEndpoint {

 @ReadOperation
 public String details() {
 return &quot;My App Details&quot;;
 }
}
</code></pre>
Restart the application and navigate to your browser to <code>http://localhost:8080/actuator/details</code>:
<img src="https://stackabuse.s3.amazonaws.com/media/spring-boot-actuator-8.png" alt="spring boot actuator custom">
<h2 id="conclusion">Conclusion</h2>
Monitoring applications may include something as simple as knowing the Health and Info to some complex data like understanding Traffic and Metrics for our application. For example, how much resources (CPU, RAM, etc.) are being used by the application.
Spring Boot Actuator provides build-in production ready endpoints that can be used for monitoring and controlling your application such as <code>/info</code>, <code>/health</code>, <code>/scheduledTasks</code>, etc.
We can also define our own endpoints to meet certain requirements by simple annotating classes with the <code>@Endpoint</code> annotation.
As always, the code for the examples used in this article can be found on <a rel="nofollow noopener" target="_blank" href="https://github.com/StackAbuse/learning-spring/tree/master/actuator">GitHub</a>.

Dhananjay Singh

In this article, we'll look into Spring Boot Actuator, which provides built-in production ready endpoints used for monitoring and controlling your Spring Boot applications.

Monitoring with Spring Boot Actuator

OpenGL is old and there isn't much literature online to learn from. Understanding the core concepts and how they work is important for everything, and especially when it comes to graphics. In this article, we'll start from the bottom and cover the important topics of OpenGL in Python.

Understanding OpenGL through Python

Darinka Zobenica

Design principles are generalized pieces of advice, used as rules of thumb when making design choices. In this article, we'll be covering the most important design principles related to object-oriented design and implement them in Java.