localForage VS client-web-storage

Not really an answer but have you looked into https://github.com/localForage/localForage

I may not be pointing you in the right direction but, please read about [IndexDB storage](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB\_API) method and packages like [localForage](https://localforage.github.io/localForage/) that use it under the hood.

LocalForage: this is a wrapper around IndexedDB, WebSQL, LocalStorage, and SessionStorage with a way to define more interfaces (called drivers) *for additional storage solutions. It does a great job handling all your serialization needs, it is **asynchronous **and handles a large set of data types. Its **API resembles Web Storage API* and it is ridiculously simple to learn.

Depending on what kind of storage requirements you have, LocalForage might be a good fit. It provides a unified API to access WebSQL, indexedDB or localStorage.

I find localForage is pretty helpful for this stuff https://github.com/localForage/localForage

localForage (https://localforage.github.io/localForage/) mirrors localStorage syntax, but uses IndexedDB in the background. If that's not supported, it uses WebSQL and then LocalStorage

This is why we have localForage.

Try Client Web Storage which supports localStorage, IndexedDb and more. Perfect for any caching needs you have.

ClientWebStorage: this is a wrapper on LocalForage — which means it inherits all its benefits —, but takes to a whole new level your data storage needs to also be your preferred application state manager. It is asynchronous, event-driven, schema-based, handles data defaults and type checks for you, allows for data action subscription and interception to handle side effects, and integrates nicely with the backend server for continuous data synchronization. It also can be used as a state management solution for any UI framework like React and Angular.

Unless you use this library: https://github.com/beforesemicolon/client-web-storage