Olympus — An intuitive hybrid caching solution for GraphQL

Marshallkkim
5 min readJun 1, 2022

--

The Problem

For quite some time now, RESTful API has been the industry standard for designing web APIs. RESTful API was designed to allow clients to send requests to various endpoints in order to retrieve content from the producer’s databases. Depending on how the producer has arranged their databases, the client may need to hit multiple endpoints in order to receive a complete set of data. Moreover, many times these endpoints send back large strings containing an array of objects which can get clunky for developers and slow down performance. The use of RESTful API has lead to issues with over and under-fetching of data.

Recently, GraphQL has gained significant traction and popularity due to its fast, flexible, and efficient API calls. GraphQL is a query language that gives the user the ability to get exactly what they want when fetching data — while only requiring the use of one request/endpoint. When compared to the traditional RESTful architecture, however, caching is still a challenge in GraphQL.

Unlike GraphQL, traditional RESTful architecture, gives users the ability to cache responses by putting an optional key in the header of the request. This feature allows RESTful API to store frequently requested data to the client in stored memory rather than querying the database again, improving response time.

“But… is caching & response times that important?”

This should come as no surprise, but if you want the users of your application to continue using it caching & response times should matter. As an application scales, it is critical that developers consider network response times, as studies have shown that over 50% of visitors leave a site if it takes longer than 3 seconds to load.

How does Olympus work?

Olympus is a hybrid caching library for GraphQL that will automatically cache your GraphQL queries/responses on your server and your client’s browser local storage. Olympus also integrates with any server running on Express/Node.js.

To get started with the Olympus library, developers will need to import a module on the client and server side. These imported functions are easy to setup/use and require minimal changes to the pre-existing codebase.

On the server-side, our middleware function has been designed to store the response returned from a query to the database in the server’s Redis cache (that we help you set up with some basic commands). Redis is an open source-in-memory database that has grown in popularity in recent years and will store key-value pairs in RAM. When a user performs a query for the first time, our middleware will check the Redis store to see if the query exists as a key — and if it does — it will return that result without going to the database. If the key is not found, the middleware will perform a fetch request to the ‘/graphQL’ endpoint and store the returned result of that request in the Redis store with the query as the key. Note that key-value pairs in the Redis store will live for 60 minutes before expiring and being deleted.

On the client-side, our Olympus function is designed to replace all instances where you make a fetch() call to the ‘/graphQL’ endpoint. The purpose of using our Olympus function instead of fetch is to utilize your users’ browser local storage — which acts as a client-side cache for GraphQL queries. When a query is made for the first time on the front end of your application, Olympus() will check to see if the query exists as a key in your user’s browser local storage. If it does, it will simply return the result of that query without making a request to the server, however, if it does not exist, it will make a fetch request to our ‘/olympus’ endpoint which contains our middleware function. The reason for this is so that we first check our Redis store to see if the query exists in the server cache before having to make a trip to the database. Note that key-value-pairs in the users’ browser local storage will be “fresh” for 10 minutes, and if a query is made after the key “expires”, nothing will be returned from local storage and instead go through the process of checking our Redis store and if necessary, make a trip to the database.

Why Olympus?
Research has shown that speed is one of the most important decisions a developer must make to attract and keep users. Given the caching shortfalls of GraphQL, developers will need to find alternative ways of mitigating the risk of overloading servers as well as reducing network traffic and bandwidth usage. By using our library, developers can optimize their response rates of their applications by utilizing the storage on their browser and server which can be accessed much quicker than the database.

Check out our demo here!

Get Involved

Visit our website to get started to use our application. You can also visit our GitHub where we have a tutorial on step-by-step instructions on how to get started. Follow us on LinkedIn to keep up to date with any added features.

Olympus is an open-source product developed under tech accelerator OSLabs. We are incredibly excited to launch Olympus and are always looking for ways to make improvements and appreciate any feedback. Feel free to submit any issues or contribute to the open-source project on GitHub.

Olympus | GitHub | LinkedIn

Olympus Engineers and Co-Authors

Adam Lang | GitHub | LinkedIn
Bryan Kim | GitHub | LinkedIn
Kevin Le | GitHub | LinkedIn
Marshall Kim | GitHub | LinkedIn

If you like this article, please send us some 👏🏽👏🏽👏🏽 so we can create more content like this! Thanks for your support, and happy caching!

--

--