Wether you are building a frontend for your website or a backend api you should be doing some forms of caching. The slowest items in your infrastructure are often limited to things like IO and index lookup times; in my experience the slowest parts of your infrastructure are database, file system IO, network IO, in that order.
Caching your data will both give the perception of your website or api being faster, but will also save you server and network resources. The first part of caching is of course figuring out how you're going to cache your data, the fastest and easiest to implement is in-memory caching. so lets build a simple memory caching application.
Similar to my Pub/Sub model we're going to create a simple object for our project and a simple object to store our cached data. We'll need a way to store items in the cache, we will want a reference key the item to store and (optionally) a way to expire the item, we need a way to retrieve the cached item and a way to clear it.
Now that we have a simple caching object, we'll need to come up with a pattern in our application to use the cache. I'm partial to qwest for my API calls.
Using the cache
Lets setup a simple caching system for customer API calls:
Now with this model you can call the api as often as you would like for your single page app and it'll only call the server side API once every 5 min instead of constantly hitting the database. Keep in mind you can build a similar structure on your server side applications as well to limit hits on your database or file system.
This is a very basic model, here are a few things that I've missed:
- Debouncing the API requests
- If you return the saved object on save, setting the cache with the return
- Cloning objects from the cache, or making them immutable, otherwise cached items are technically editable after being returned.
npm install medusajs