Caching with GraphQL: What are the Best Options?

A recent Google study concluded that increased page response times of 400 ms results in a 0.44% decrease in traffic. A 400 ms lag on a Google page therefore leads to 440 million abandoned sessions a month, amounting to an incredible loss of advertising revenue for the site and potential sales of goods and services. As of February 2018, Google observed that 53% of page visitors leave the page if it takes more than three seconds to load. A neural network trained to predict user behavior with 90% accuracy revealed that as page-load time goes from 1 to 10 seconds, the probability of a site visitor bouncing increases to a staggering 123%. Long story short: if you build it slow, they leave.

In an effort to mitigate response latency, we can store response data in hardware or software components not only on the server or at the database, but also on the client’s machine. When future requests are made, that data will be delivered in lieu of a costly round-trip to our databases. By leveraging storage on the user’s device we can vastly improve the experience of our users.

Options for Caching With GraphQL

The advent of GraphQL shifts the paradigm of interactive, performant web applications — and by proxy, HTTP caching. Endpoint-based API’s are able to utilize the full capabilities of HTTP protocols to cache response data, but GraphQL dispatches queries through POST requests to a single endpoint. HTTP serves as a pipeline of sorts for requests and responses to flow through. Furthermore, the complex and dynamic structure of GraphQL queries limit the predictability of request structures that we’ve become accustomed to, and necessitates a flexible caching engine to normalize request and response bodies into a readily usable form. Currently, few such libraries exist to reconcile these challenges.

Libraries such as Apollo and Relay are the most widely implemented for the GraphQL specification, and offer an immense range of functionality. Apollo is a fully-featured library for GraphQL applications, providing tools and libraries across the stack. Apollo offers the ability to transform an existing RESTful architecture into a GraphQL instance by wrapping your endpoints, providing users with a responsive caching engine for GraphQL servers, and offering tools for interfacing with the client-side. However, for user facing applications interfaced with existing GraphQL backends, the weight and challenges implicit in the implementation of these larger libraries can be undesirable.

Alternatives to Larger Libraries

FlacheQL is a recently developed, open-source alternative to these larger libraries for the purpose of caching the client. It offers the advantage of being lightweight, and incredibly easy to setup and integrate into your application. FlacheQL’s simple implementation utilizes the client’s local storage to provide lightning fast retrievals for cached queries, typically on the magnitude of 150% faster than those offered by Apollo.

FlacheQL also has the distinct advantage of being able to return subsets of cached responses on search parameters, which no other caching engine offers. This means that if you search for Github repositories tagged with React and with 1000 stars, then subsequently dispatch a query with the same parameters but with 3000 stars, FlacheQL will immediately return the results from the cache, while libraries like Apollo and Relay would have to make another trip to the database. This feature is enabled by an advanced comparison algorithm that ascertains equivalence among subsets of queries. After a developer defines a schema of subsets for the data that they expect in their application, FlacheQL will interpret queries in order to return the relevant data based on the kinds of subsets determined by the search parameters.

Like Apollo, FlacheQL uses a normalized map to store requests and responses, and thus is capable of returning data contained in individual fields of cached responses. An initial query that is dispatched searching for the date created and database IDs of repositories will fetch from the endpoint, and subsequent queries matching the same parameters but only requesting the database ID will be served from the cache. These two features allow FlacheQL to adapt to the flexible, user driven nature of the GraphQL specification, and vastly increase the UX and performance metrics of an application.

Choosing The Right Library

One of the most important elements to consider in choosing a caching library is the type of caching that will serve your application’s needs. GraphQL queries are often composed of search parameters and fields. FlacheQL was designed to offer both types of caching. Here are a few examples of queries that hit the Yelp API:

If you’re dealing with a large application that requires only partial retrievals on query fields, Apollo or Relay can integrate with Redux, for example, in order to use their caches as the since-source-of-truth in your application. However, if you’re dealing with a smaller app where speed is a central concern and where caching on both parameters and fields (or just on parameters) is a necessity, FlacheQL may be the better option.

As software engineers, we implement caching to increase the performance of our applications and decrease loads on our servers. Caches are everywhere: from the database, to a proxy server, all the way to the client. When we begin to consider the UX of our applications, these principles and practices become especially relevant. Choosing the right caching library for GraphQL will help you develop more performant applications that yield minimal page abandonment.

For more information and to interact with a demo of FlacheQL’s power, please visit www.flacheql.io , check out and star the GitHub repository, and play around with it on your user-facing applications!