Our great sponsors
-
localForage
💾 Offline storage, improved. Wraps IndexedDB, WebSQL, or localStorage using a simple but powerful API.
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
Alternatively, there's localForage[1].
1. https://localforage.github.io/localForage/
I ran into the IndexedDB slowness problem while adding support for it to Converse.js XMPP messenger.
I'm using localForage which lets me persist data to either sessionStorage, localStorage or IndexedDB (depending on user configuration), however writes to IndexedDB were excruciating slow.
I didn't want to give up on it however, because localStorage has a storage limit that power users were constantly coming up against, and IndexedDB is also necessary for progressive web apps.
Eventually I solved the problem by batching IndexedDB writes with a utility function I wrote called mergebounce[1]. It combines Lodash's "debounce" and "merge" functions to combine multiple function calls into a single one, while keeping and merging the data that was passed to the individual function calls.
That way, you can call a function to persist data to IndexedDB many times, but it only executes once (after a small delay). I wrote a blog post about this approach[2]. It's generic enough that anyone else who uses localForage for IndexedDB could use it.
1. https://github.com/conversejs/mergebounce
This mentions Absurd-SQL[0] which I only discovered recently. It’s seriously clever, worth reading the blog post[1] to see how it works!
I think there is a good chance Absurd-SQL will get folded into SQLite.js.
0: https://github.com/jlongster/absurd-sql
1: https://jlongster.com/future-sql-web
I'm more interested in read speeds than write speeds. I have about 2 MB of data that I fetch, then parsed and transformed into a heavily nested object for easy look-up by various types of keys.
In my brief experiment, it was 12% faster to read from the web Cache API, re-parse and re-transform that heavily nested object than to read the fully transformed object via IndexedDB. That surprised me! My understanding is that IndexedDB does a structured clone as part of the read, which I suspect is the main cause of slowness of IndexedDB relative to the Cache API approach in my use case.
Related commits to reproduce that finding are in [1], specifically [2].
[1] https://github.com/eweitz/ideogram/pull/285