DB64: Fixing IndexedDB’s Ugliness in JavaScript

IDB is an underlying technology which becomes more consumable with the use of wrapper libraries. One of its biggest limitations is down to immutable schemas, enforcing versioning. Let’s explore how DB64 can circumvent versioning restrictions.

(Btw, IndexedDB is not part of the JavaScript specification)

I made DB64, a tiny IndexedDB wrapper to make using IndexedDB less hellish. e.g.

• You create your DB and Stores (Like tables)
• Use a particular store of a given DB (Similar to SQL SELECT * FROM db_name.table_name;)
• Set and get entries
• Handle exceptions (E.g. If someone clears their cache what do you do?) the has method was introduced to help facilitate storage eviction and data invalidation.

LocalStorage has the same storage eviction and data invalidation risks but its often ignored because of the limited simplicity of its API.

Version 0.8.5 introduced the ability to re-create databases that have missing stores with new stores included.

By default, if the database to create exists but doesn't have the expected stores, it will be deleted before being re-created. This can be disabled by using the 'disable-delete' string.

Because we’re eliminating versioning its crucial to emphasise the edge cases that versioning aimed to solve in the most cumbersome way imaginable.

You cannot delete or add a Store to IndexedDB

Therefore, in DB64 you can clear a store or delete a database but you cannot add or delete a store due to the “schema change versioning requirement”

If you’re well versed in the world of IDB you could be thinking “why not just create a new version and setVersion?”

It’s never “just” with IDB. Also, IDB accumulates over time. Even if we assume it uses snapshots or a DAG algorithm similar to Git, it’s still a sledgehammer cracking a boiled egg for the majority of the web that never asked for versioning.

A practical solution

In Release 0.9.x, DB64 will introduce the ability to add and delete stores without versioning. This will be done simply by:

• Defining the new empty schema.
• Copying the existing data from the current schema.
• Deleting the existing schema.
• Creating the new schema with the added or deleted object stores.

This is not a technical masterpiece, it’s a simple idea that will literally

make DB64 easier to use than LocalStorage

This is not far-fetched, since LocalStorage requires serializing and deserializing to and from JSON or a regular string. This can also make it more prone to human error.

With IndexedDB and DB64 , you can find yourself having one database evicted while the others continue to operate fine.

Though with LocalStorage, in that scenario all of your data is lost at once. Therefore, if you need to make, for example, 8 HTTP requests to repopulate, it introduces another inefficiency and a potential point of failure. (Now you have to consider which requests fail or partially fail).

After this upcoming feature, DB64 will next explore wrapping the utility aspects of IndexedDB as well as IDBCursor, so you will not need to use both DB64 and IndexedDB when performing more advanced tasks.