Object caches go a long way in helping us secure the benefits caching delivers to the scalability and user experience of our web applications. Object caches are built on key-value stores, a simple type of database that matches a unique key to a value. Typically, these systems are simple to integrate into an already existing application and come with features useful to caching. Caching objects save us time and resources because we can retrieve them from our store rather than perform the computing to build them again. Object caches come in different types following the same principle. Let's explore common types of object caches.
Client-Side Caches
Client-side caching is enabled by technologies that allow our applications to store objects in the user's device, preferably for as long as possible. For the web, most modern browsers support the Web Storage API, a programming interface for storing key-value pairs locally. Client-side caching is especially beneficial in increasingly common Single Page Applications or SPAs, which tend to make many AJAX request. Each request means time spent as the data travels to and from our servers, plus the time to compute or retrieve the requested information. By leveraging local storage and storing frequently requested data, we can decrease the load on our servers as well as provide a snappier user experience.
To get started with the Web Storage API, open up your browser console and follow along with these snippets. All the following methods belong to the localStorage object, which itself belongs to the window object.
To store a new key-value pair, use setItem:
localStorage.setItem('REPLACE WITH KEY', 'REPLACE WITH VALUE');
// returns undefined
Using the method above will either set a new value to your key or replace the old value if the key is already in use. To retrieve the value, use getItem.
localStorage.getItem('REPLACE WITH KEY');
// returns 'REPLACE WITH VALUE'
Deleting specific values is also straightforward with the use of removeItem.
localStorage.removeItem('REPLACE WITH KEY');
// returns undefined
Now if we try to retrieve that same value...
localStorage.getItem('REPLACE WITH KEY');
// returns null
Clearing all the key-value pairs we've created is also possible with localStorage.clear().
Caches Co-located with Code
Caching close to our code refers to storing our key-value pairs either in places that are easy for our application logic to access. For example, our application's memory, which we can use when declaring an appropriate data structure cache data. Alternatively, we can deploy an independent cache server on the same machine for each of our web servers. Both methods have the benefit of being close to the code, so accessing them is relatively quick. Additionally, the code to access an independent service on the same machine won't be hard to adapt should you wish to connect to a remote service later on. The most popular key-value stores I've come across are Redis and Memcached. When looking to scale would architect our application so that we can have many web servers, meaning this type of cache scaled alongside them.
When we deploy a cache server locally, however, we also face limitations. For example, each web server is only aware of a singular cache and will replicate data by storing information another web server has already cached. Additionally, removing cached data is difficult since we usually communicate with one server at a time but it might be cached on multiple machines.
Distributed Object Caches
A distributed object refers to when our cache servers with software like Redis or Memcached lives on a separate host machine accessed over the internet. Distributed caches systems have the advantage of scaling very well, making it possible for our application to interact with multiple caches on a cluster as if it were one. The cache system will also be responsible for intelligently utilizing the resources available, combating the issues mentioned earlier of replication, and trouble deleting. Distributed object caches can scale vertically or horizontally to meet your application's demands without too much complexity.
Thanks for reading :)
Original cover photo by Pixabay, edited by me.
Top comments (0)