What is the right approach to cache data in your solution?

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.

All client-side

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

Session storage

The 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.

Local storage

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.

IndexedDB

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.

Show image

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.

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).

1
-------------------------
2
spfx-ndsi-1602769746742-197: 183987 Bytes => 0.17546367645263672 MB
3
spfx-ndsi-1602751398844-478: 256225 Bytes => 0.2443552017211914 MB
4
spfx-ndsi-1602751393221-402: 192882 Bytes => 0.1839466094970703 MB
5
spfx-ndsi-1602769742738-121: 502457 Bytes => 0.47918033599853516 MB
6
spfx-ndsi-1602769746715-521: 294128 Bytes => 0.2805023193359375 MB
7
Keys Starting With: spfx-ndsi
8
Total Keys: 5
9
Total Length: 1429679
10
Total Length (in MB): 1.363448143005371
11
-------------------------
12

13
-------------------------
14
odsp-ds-ViewNavDataSource-version: 36 Bytes => 0.000034332275390625 MB
15
odsp-ds-FavoriteFeed-version: 36 Bytes => 0.000034332275390625 MB
16
odsp-ds-acronymAndColors: 2 Bytes => 0.0000019073486328125 MB
17
odsp-ds-FavoriteFeed: 2 Bytes => 0.0000019073486328125 MB
18
odsp-ds-SiteDataSource({0209078f-7066-4a2c-b363-53d5ff3683bb})-version: 36 Bytes => 0.000034332275390625 MB
19
odsp-ds-AudiencesDataSource-version: 36 Bytes => 0.000034332275390625 MB
20
odsp-ds-acronymAndColors-version: 36 Bytes => 0.000034332275390625 MB
21
odsp-ds-SiteDataSource({fd5cd288-9f51-4560-aa2f-e42f8c90f54e})-version: 36 Bytes => 0.000034332275390625 MB
22
odsp-ds-ViewNavDataSource: 2 Bytes => 0.0000019073486328125 MB
23
odsp-ds-SiteDataSource({0209078f-7066-4a2c-b363-53d5ff3683bb}): 2 Bytes => 0.0000019073486328125 MB
24
odsp-ds-SiteDataSource({fd5cd288-9f51-4560-aa2f-e42f8c90f54e}): 2 Bytes => 0.0000019073486328125 MB
25
odsp-ds-AudiencesDataSource: 2 Bytes => 0.0000019073486328125 MB
26
Keys Starting With: odsp-ds
27
Total Keys: 12
28
Total Length: 228
29
Total Length (in MB): 0.000217437744140625
30
-------------------------
31

32
-------------------------
33
mssearchux-cache-sphome-mappednews: 35710 Bytes => 0.03405570983886719 MB
34
mssearchux-cache-sphome-mappedprefetch: 56881 Bytes => 0.054245948791503906 MB
35
mssearchux-cache-psst: 7388 Bytes => 0.007045745849609375 MB
36
mssearchux-cache-searchConfiguration: 6669 Bytes => 0.006360054016113281 MB
37
mssearchux-cache-spsites-activitiesprefetch: 79790 Bytes => 0.07609367370605469 MB
38
mssearchux-cache-pspd: 1564 Bytes => 0.001491546630859375 MB
39
mssearchux-cache-3sqf: 7904 Bytes => 0.007537841796875 MB
40
mssearchux-cache-searchcenterurl: 233 Bytes => 0.00022220611572265625 MB
41
mssearchux-cache-site-activities-rawsprefetch: 311950 Bytes => 0.2974987030029297 MB
42
mssearchux-cache-warmupMsb: 716 Bytes => 0.000682830810546875 MB
43
mssearchux-cache-warmupSubstrateSearch: 244 Bytes => 0.000232696533203125 MB
44
mssearchux-cache-personalaccountname: 752 Bytes => 0.0007171630859375 MB
45
mssearchux-cache-searchConfigurationFromEcs: 7126 Bytes => 0.0067958831787109375 MB
46
mssearchux-cache-sphome-rawnews: 345187 Bytes => 0.3291959762573242 MB
47
mssearchux-cache-sphome-rawsprefetch: 98427 Bytes => 0.09386730194091797 MB
48
Keys Starting With: mssearchux-cache
49
Total Keys: 15
50
Total Length: 960541
51
Total Length (in MB): 0.9160432815551758
52
-------------------------
53

54
remainingStorage: 2316080
55
remainingStorage (in MB): 2.2087860107421875

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.

Happy developing