With version 1.26 of Deno, the team released support for the Web Cache API, which provides an accessible way of storing Request and Response data for a certain amount of time.

There are still some unimplemented features, but the release so far looks very promising.

Let’s take a look at what that means for you as a developer.

But before we move forward, remember that you have to use using Deno version 1.26, so in case you haven’t yet, upgrade your local install with deno upgrade .

Now we’re ready to move on!

An overview of the Cache Web API

This is an API that browsers can implement and allows them to cache (well, clearly) a response for every request made. Given the right circumstances, the cache can greatly improve the performance of an app by avoiding the round trip to the server.

The functionalities are not very advanced, in fact, you basically can add, remove and query a cache to understand if a request has already been cached. And that’s it, the power of this API relies on the fact that you’re given the basic building blocks to create exactly what you need.

That is already amazing by itself, but given how Deno is now also implementing this API, you can do the same, but on the back-end.

Now, of course, you’re not saving the round trip from the client to the server and back, because now you’re using the cache on the back-end, you can still benefit from the cache by saving time skipping complex business logic and even some requests to other APIs.

Essentially, you’re still able to cache the response your API would return for any particular request, by using the Cache API.

It’s not done yet though

While this news sounds amazing, the current implementation is not complete yet.

Deno has implemented so far the following methods:

But there are other, secondary ones, that are not ready yet. Methods such as Cache::add() or Cache:keys() which are useful but not strictly necessary to make use of the cache API.

What can you do with it?

Let’s take a look at a code sample and see how exactly we can take advantage of this API for our Deno projects.

This example boots up a very simple HTTP server that gives you a random activity whenever you send your name:

You can run the example with the following line: deno run --allow-net index.ts

Now, in my system, executing this code takes on average 100ms as seen from the browser.

We can improve this by using the Cache API on our server.

The steps are (assuming you’re already using Deno 1.26, otherwise upgrade the version first and then keep going):

1. Initialize the cache with the CacheStorage.
2. For every request, check if the request has been cached.
3. If it has, return the cached response.
4. Otherwise, execute the whole code and save the response inside the cache before returning it.

Let’s see what the updated, cache-powered code looks like:

You can see where each step fits into the code.

Notice how I’m cloning the response object when I save it on the Cache. This is because you can’t “consume” (or read) the response more than once. If you tried to save the original response into the cache, the moment you tried to return it, you’d get an error message.

This way you’re saving the data without affecting the response.

Also, notice how the CacheStorage service is actually available globally on Deno in the caches variable.

Now, the million-dollar question: have we improved our performance in any way? Let’s see.

I’d say we did, after all, we went from 100ms to 2ms. That’s a huge improvement. Of course, this example is designed to be cached, and thanks to our caching strategy, we’re avoiding most of the logic, so it makes sense that we get such a huge performance improvement.

Did you like what you read? Consider subscribing to my FREE newsletter where I share my 2 decades’ worth of wisdom in the IT industry with everyone. Join “The Rambling of an old developer” !

What’s not so great about the Cache API?

There are no perfect APIs, there is always a trade-off, and in this case, the same rule applies.

In case you didn’t notice, the above code is creating a cache and putting in some entries that will never be removed. Essentially, the idea of a stale cache doesn’t exist in my logic, which means I’m also removing the possibility for the cached data to change.

This is all to say that the API does not give you any of these tools. You’ll need to write your own Cache management logic and determine what to do with cached data once it becomes outdated in comparison with the original source.

The “bad” part here is that Deno hasn’t implemented the Cache.keys method, which is crucial to inspect the content of the cache and understand what you want to do with it.

It might be that we’ll need to wait a little longer until they release full support for the API before we can start thinking about taking it to production, especially if you’re looking to cache a lot of data.

The Web Cache API is a very useful API to have access to as web developers, and the fact that Deno is starting to implement it, shows they care about giving you the tools to follow the standards.

The current implementation of it is not yet done, and that means it lacks certain features for it to be “production-ready” for everyone.

But it’s just a matter of time before they release a fully compatible version.

Have you tried this API already? What are your thoughts on it?

Build composable web applications

Don’t build web monoliths. Use Bit to create and compose decoupled software components — in your favorite frameworks like React or Node. Build scalable and modular applications with a powerful and enjoyable dev experience.

Bring your team to Bit Cloud to host and collaborate on components together, and speed up, scale, and standardize development as a team. Try composable frontends with a Design System or Micro Frontends, or explore the composable backend with serverside components.

Give it a try →