We all want to be the fastest. We all want to make sure our apps outperform others, but what do you need to do for it? In this article, I will explain what the best approach is to cache your solutions.
Important When building on top of a platform like SharePoint, you will always have to deal with the fact that you cannot be faster than the platform itself. First-party gets priority over third-party.
As you create most solutions (SharePoint/Microsoft Teams) these days with code that runs on the client their devices, performance is critical. For this, you should not do too many API calls, use small bundles, compress images, have an excellent CDN and cache policy.
The hardest thing in this is the number of API calls, in my opinion. If you want to show data, you need to make API calls. That is the only way forward, and you can make it more performant by caching this data.
Caching API requests
If it is an API you own, you can implement a cache on both the API (server-side) and the client (browser). If you use Microsoft Graph or any other API you do not own, you will have to rely on the browser.
Your options for caching are local-, sessionStorage, and IndexedDB. The local- and sessionStorage are the easiest ones to use. IndexedDB is great for more massive data sets, but the APIs are a bit bulky to use.
Storage types explained
sessionStorage is great for when you want to cache data for its current session. This type of storage is often used, for example, to store the OAuth access tokens. When the user opens a new tab or browser window, it creates a new session.
This type of storage is similar to the
sessionStorage apart from the persistent data. Your data gets saved across all browser sessions. Also, when you close and reopen a tab/browser.
As the name describes, this is a database in your browser. It allows you to do SQL-based transactions. This type of storage is great for larger amounts of data or when you want to work offline.
When to use what?
Before I tell you what to use, you need to know that local- and sessionStorage have a limit of 5MB data storage. For storing API requests, this is a lot of space you can use.
Are you the only one using it?
When you maintain the site, platform, or solution, you can certainly use the local- and sessionStorage. Only when you know when you will need to store more data, you might want to think about IndexedDB.
What if you are building on top of a platform?
On SharePoint, you are, for sure, not the only one. Besides all the first-party solutions, you might have to take the third-party components also into account. Why? The reason is that each one of these components can take their share of the cake. Once you reach the local- or sessionStorage limit, depending on your solution, it might fail or slow down as data cannot be cached or retrieved from the cache. Of course, this could also affect the first-party or any other third-party components from using the storage.
When building solutions that will run on top of a platform you do not own, I would recommend using
IndexedDB. With IndexedDB, you will avoid running into the space limit as its limit is the user’s disk space.
Important There is a downside using
IndexedDB. The downside is that the APIs feel like they were invented in 1999. They feel outdated and too complicated to use. Funny enough, this is something they are aware of. On the Mozilla Developers documentation IndexedDB API they even recommend using a library to make it easier.
Would IndexedDB not just be overkill?
Initially, I would have said yes to this question, but times changed, SharePoint became a lot more popular. SharePoint Framework itself became more popular, so everyone starts to cache. Here is an example of an OOTB team site in my environment (no customizations).
Info Here are only the ones logged that take the most space. When starting to search and navigating through the environment, this number goes up quickly as you can see at the end of the log, only 2MB available out of the 5MB.
Making your life easier
For the solutions we create at Valo, I thought why not make a dependency that makes it easier to use the IndexedDB for caching data.
The dependency called
@valo/cache is available on npm: @valo/cache.