IndexedDB ist eine im Browser integrierte Datenbank, die entwickelt wurde, um clientseitiges Speichern von großen Datenmengen und komplexen Datenstrukturen zu ermöglichen. Trotz ihrer starken Position als einzige für große, strukturierte Datenspeicherung geeignete Browser-API, handelt es sich um ein System, das viele Entwickler als merkwürdig und umständlich empfinden. Diese Wahrnehmung rührt vor allem von der Art und Weise, wie IndexedDB funktioniert und wie es im Kontext von JavaScript genutzt wird, her. Im Folgenden lohnt sich ein genaues Hinsehen, warum IndexedDB trotz seiner Funktionen als „weird“ gilt und wie man die Eigenheiten bewältigen kann, um die volle Leistungsfähigkeit zu nutzen. IndexedDB entstand vor einer Dekade, genauer gesagt, die ersten Entwürfe wurden um 2009 vorgestellt.
Die erste Implementierung in Browsern folgte etwa 2011. Damit gehört IndexedDB zu den älteren Webtechnologien. Zum Zeitpunkt ihrer Entstehung gab es in JavaScript noch keine Unterstützung für Promises oder asynchrone Funktionen. Das heißt, alle asynchronen Operationen wurden über Callbacks realisiert, was aufgrund der Single-Thread-Natur von JavaScript ein notwendiges Übel war, um die Nutzeroberfläche nicht zu blockieren. Genau hier beginnen viele Entwicklerinnen und Entwickler, sich über den merkwürdigen Charakter von IndexedDB zu wundern.
Denn die API ist komplett callback-basiert – auch wenn moderne JavaScript-Sprachen mittlerweile Promises und async/await bevorzugen. Das führt zu einem sogenannten „Callback-Hell“: Code wirkt verschachtelt, schwer lesbar und wartbar. Zwar ist es möglich, Wrapper zu schreiben, die IndexedDB mit Promises kompatibel machen, doch dieser Aufwand bringt zusätzliche Komplexität und potenzielle Fehlerquellen mit sich. Die Beschränkungen der IndexedDB-API hören an dieser Stelle aber nicht auf. Das Interface wurde bewusst schlank gehalten und bietet nur eine sehr eingeschränkte Menge von Abfragefunktionen.
Während viele NoSQL-Datenbanken flexible Abfragesprachen bieten, sind die Möglichkeiten bei IndexedDB rudimentär. Man kann beispielsweise mit getAll() alle Einträge abfragen, die einer Bedingung entsprechen, oder mit index().openCursor() Einträge einer Range durchlaufen – aber komplexe Operationen wie JOINs oder logische Verknüpfungen (AND, OR) sind schlichtweg nicht vorhanden. Dieses vereinfachte Design hat historische Gründe. Ursprünglich war geplant, im Web eine SQLite-Datenbank mit vollem Funktionsumfang zu nutzen.
Mozilla setzte sich aber dagegen durch, weil ein Webstandard nicht von einem spezifischen Datenbanksystem abhängig sein sollte. Das Ergebnis: Eine Datenbank, die in der Theorie viele Features eines vollwertigen SQL-Datenbanksystems besitzen könnte, diese aber nicht offenlegt oder nutzbar macht. Entwickler sind damit gezwungen, komplexe Logik außerhalb der Datenbank in JavaScript zu implementieren – was sowohl Performance- als auch Wartungsprobleme nach sich ziehen kann. Darüber hinaus fehlen bei IndexedDB fundamentale SQL-Features wie LIMIT. Gerade bei großen Datenmengen ist es häufig notwendig, nur eine Teilmenge der Ergebnisse auszulesen.
In IndexedDB muss man stattdessen auf die Cursor-API zurückgreifen und die gewünschte Anzahl der Datensätze im Code selbst abfangen und verwalten. Diese Herangehensweise bringt eine Menge zusätzlichen Code mit sich und kann je nach Implementierung erhebliche Performance-Nachteile haben. Ein weiteres Missverständnis entsteht oft bei den Transaktionen in IndexedDB. Im Gegensatz zu vielen Datenbanksystemen, in denen eine Transaktion erst durch einen expliziten Commit abgeschlossen wird, sind die Transaktionen in IndexedDB eng an den Event-Loop von JavaScript gebunden. Das bedeutet, dass eine Transaktion automatisch als abgeschlossen oder „inactive“ gilt, sobald der JavaScript-Thread an den Event-Loop zurückgibt ohne weitere Aktionen auf der Transaktion durchzuführen.
Diese Funktionsweise hat große praktische Auswirkungen. Entwickler können beispielsweise keine Transaktion in einem asynchronen Kontext über ein await hinaus offenhalten, da die Transaktion bei Rückgabe an den Event-Loop automatisch zugesprochen wird. Dies führt häufig zu Fehlern, wenn im Transaktionskontext asynchrone Wartezeiten genutzt oder große Anzahl von Datensätzen schrittweise eingespielt werden sollen. Ein populäres Problem dabei ist das Aktualisieren von Nutzerinterfaces während langer Transaktionsprozesse. Wenn man etwa einen Ladebalken anzeigen möchte, der den Fortschritt einer großen Anzahl von Einträgen signalisiert, funktioniert das nicht ohne Weiteres.
Läuft der Code ohne Zwischenschritte durch, „friert“ die Seite ein, da der JavaScript-Thread vollständig ausgelastet ist und erst danach alle Callback-Events abgearbeitet werden können. Versuche, die Transaktion durch permanente, kleine Dummy-Anfragen künstlich am Leben zu erhalten, schlagen fehl oder führen zu anderen unerwarteten Problemen. Das liegt daran, dass IndexedDB-Anfragen, die nach einem Event-Loop-Übergang außerhalb eines Callbacks für die aktive Transaktion gestellt werden, abgelehnt werden. Nur in Callback-Funktionen auf eine bestehende Anfrage hin können weitere Datenbankaktionen zuverlässig erfolgen. Der Schlüssel zum Verständnis ist also, dass neue Aktionen innerhalb der Transaktion nur aus einem Callback heraus starten dürfen.
Daraus ergibt sich ein besonders gestaltetes Muster, um viele Schreiboperationen nebenläufig und ohne Blockierung zu realisieren. Eine bewährte Lösung besteht darin, eine Warteschlange von Einfügungen („puts“) maintained und schrittweise nur bis zu einer bestimmten Anzahl an gleichzeitigen Anfragen aktiv zu halten. Erst wenn eine der Anfragen erfolgreich abgeschlossen ist, wird eine neue Anfrage aus der Warteschlange gestartet. Dieses Vorgehen erlaubt, ohne große Blockierung der Hauptthread-Ausführung hocheffizient große Mengen von Daten in die IndexedDB zu schreiben und gleichzeitig UI-Elemente, beispielsweise Progress Bars, flüssig zu aktualisieren. Allerdings hat dies zur Folge, dass der Code sehr stark von Callbacks abhängig bleibt und schwer mit async/await-Manipulationen kombinierbar ist.
Die Eigenheiten von IndexedDB machen die API zwar komplex und auf den ersten Blick unzeitgemäß, doch die enthaltenen Konzepte beruhen auf technischen Limitationen und Entscheidungen, die zur Zeit der Entwicklung sinnvoll waren. Für Entwickler bedeutet dies, dass ein gutes Verständnis der zugrundeliegenden Asynchronitätsmechanismen und Transaktionsverwaltung unerlässlich ist. Nur so lässt sich das Maximum an Stabilität und Performance aus IndexedDB herausholen. Trotz all dieser Komplexitäten ist IndexedDB aber für viele Webanwendungen unverzichtbar. Es ist die einzige native Lösung, die offline-fähige Web-Apps mit großen Datenbanken versorgen kann, insbesondere dann, wenn Daten strukturiert und dauerhaft gespeichert werden müssen.
Beliebte Anwendungsbereiche sind beispielsweise Browser-basierte Notiz- und Organisationssoftware, Offline-fähige Editoren, große Caches von Medieninhalten oder Progressive Web Apps mit synchronisierbareren Datenbanken. In den letzten Jahren haben JavaScript-Bibliotheken wie Dexie.js oder idb dazu beigetragen, die Arbeit mit dieser API erheblich zu erleichtern. Diese Abstraktionsschichten kapseln die Callback-Struktur elegant weg und ermöglichen die Nutzung moderner asynchroner Syntax, sodass sich Entwickler mehr auf die Logik der Anwendung konzentrieren können und weniger sich mit den technischen Fallstricken von IndexedDB herumärgern müssen. Auf der anderen Seite sollten Entwickler realistisch bleiben, was den Datenbankentwurf und die Abfragekomplexität angeht.
