By caching API responses and removing the need for a round trip over the wire to a remote API service, you save on future API calls (potentially saving you money) and create a far more responsive API. For these reasons, all of Stormpath’s primary SDKs have a caching layer built in, standard. In this post, we’ll examine the default cache in the Java SDK and how to easily replace it with the Hazelcast distributed, open source, caching server. The code for this can be found here.

If you’re a developer, you’re living in an API world. From Google Maps, to Twilio Messaging to Stormpath for Identity Management, web apps are more and more the “glue” between APIs. Many APIs are organized like old-school Utilities – you pay for what you use and how often you use it. At Stormpath, we have SDKs in many languages – Java, .Net, Node.js, Python and many more. We are often asked the question, “Why should I use your SDK instead of your API directly?” Among the answers is: Cache.

Hazelcast, Stormpath, and Caching

The Java SDK has a robust caching layer out of the box that, while configurable, requires no intervention in most use cases. And, because it’s implemented at the lowest layers of the Java SDK, you get the benefit of the cache in all the integrations, including Spring Boot.

However, the built-in cache is suitable only for single JVM environments. This means that when your application is ready to scale—perhaps to a multi-server environment, fronted by a load balancer—you’ll need to switch to a distributed caching infrastructure.

Distributed caching software, like Hazelcast, automatically synchronizes the cache across a cluster. It also has advanced features like auto-discovery and auto-assimilation of new nodes.

The Java SDK is designed so that the caching mechanism is completely pluggable. Dropping in Hazelcast is as simple as adding the dependency and creating a single configuration for your Spring Boot application.

Hazelcast + Stormpath = Love

Scaling the Cache

To add Hazelcast to your Spring Boot application, add these dependencies to your pom.xml file:

These dependencies are the baseline Hazelcast system and the Hazelcast Spring integration.

Next, we’ll add in a configuration using the @Configuration annotation.

The beans, organized this way, will override the default CacheManager. Notice lines 6 and 7 above. We are enabling jmx in Hazelcast which we will use to confirm that Hazelcast is working later.

Distributed Caching in Action

If you haven’t done so already, follow the Quickstart instructions to setup a Stormpath account.

We’ll also be using the jvisualvm tool to examine what’s going on in Hazelcast.

Next, we’ll fire up two instances of the Spring Boot app:

You’ll notice Hazelcast starting up and discovering and connecting to the second instance:

Let’s login to the Spring Boot app so we can get some good stuff into cache.

Hazelcast and Stormpath

Log in to Spring Boot

Localhost Hello Micah!

Launch jvisualvm, and you should see the two Spring Boot instances you just started:

Launch Java VisualVM

Double-click one of the Spring Boot processes and choose the MBeans tab. Note: You’ll need to install the MBeans plugin in jvisualvm.

Expand the com.hazelcast node all the way down to IMap. There, you will see some Stormpath objects:

Stormpath Objects

Click on Account on the left and the Operations tab on the right. Blank out the placeholder String to the right of the values button and then click it. You’ll get back something like this:

At this point, you may be wondering why we’ve gone through all this! Here’s the big reveal.

If you repeat the same process in jvisualvm for the second Spring Boot instance, you will see the same results.

So, firstly we’re seeing that Hazelcast is caching key elements of our session. And, secondly, Hazelcast is automatically synchronizing the cached information from instance to the other in the cluster.

Cache with Hazelcast and Stormpath for Fun and Profit

The sample Spring Boot application used in this post has a total of 3 classes: the Application, a Controller, and a Configuration. It’s the Configuration class that overrides the default built-in cache and replaces it with the distributed Hazelcast system.

You could have any number of instances of the Spring Boot app. Hazelcast auto-discovers the nodes and synchronizes the cache – even if a new Hazelcast node is started after data has already been cached in it.

For extra credit, if you log out of the app in your browser and log in again, you will notice that the /accounts endpoint is not hit a second time since the account information is coming from the cache. You can see this in the log output of the app.

Spring’s CacheManager interface and the design of the Stormpath Java SDK make it super easy to drop in an external cache system and override the default built-in cache.

Learn More

Learn more about how Stormpath supports complete Identity Management across the Java and Spring ecosystems in our product documentation, or through any of these great resources:

  • A Simple WebApp with Spring Boot, Spring Security, and Stormpath — In 15 Minutes
  • A Beginner’s Guide to JWTs in Java
  • Single Sign-On for Java in 20 Minutes with Spring Boot and Heroku