© istockphoto.com/yudhistirama
Heilige Replication, Batman!

Pouch und Couch als dynamisches Duo


Wie zwei bekannte Comicsuperhelden in Gotham City macht sich momentan ein äußerst dynamisches Duo im Bereich „Datenbanken im Web“ einen Namen: CouchDB und PouchDB [1].

Während CouchDB [2] hierzulande kein unbeschriebenes Blatt mehr ist, hat das Projekt von Apache im vergangenen Jahr insbesondere international durch das Offline-First-Framework Hoodie [3] und durch die Akquisition von Cloudant [4] durch IBM – Cloudant betreibt DB as a Service mit eigenem CouchDB-Fork – an Sichtbarkeit und Renommee dazugewonnen. Auch der NoSQL-Trend vergangener Jahre hat CouchDB im Zusammenhang mit dokumentenbasierenden Data Stores immer mal wieder auf die Agenda gebracht. Allerdings wurde das als marketingbescheiden geltende CouchDB-Projekt oftmals durch die vor allem im Web starke Konkurrenz und durch Trittbrettfahrer in den Hintergrund gedrängt. Dennoch erlangt CouchDB gerade jetzt an mehr Momentum. Der Grund dafür weht allerdings aus einer Richtung, aus der man ihn nicht erwartet. Die Aufmerksamkeit, die CouchDB weder durch NoSQL noch durch Big Data zuteil werden konnte, bekommt es nun durch das Thema „Browser Data Storage“.

Man merkt schnell, dass die Browserlandschaft hinsichtlich des Data-Store-Supports eher einer Buckelpiste gleicht: Zu ungleich sind bisher die Standards, zu unterschiedlich die Implementierungen. Auch um Daten aus der Browserdatenbank in die Serverdatenbank zu bekommen, musste man derweil eine Menge aufwändige und seltsam anmutender Verrenkungen machen. An dieser Stelle kann eine „Pouch-plus-Couch“-Combo viele befriedigende Antworten bieten.

Traditionelle Stores

Manchmal erscheint einem die Zeit vor HTML5, wie es im alten Testament geschrieben steht: Die Browser-Validations waren streng zu Regelsündern, Standards wurden zugunsten von Features geopfert und Daten browserseitig zu speichern war vergleichbar aufwändig wie Steintafeln meißeln – denn man konnte nur unwesentlich mehr Datenvolumen in einen Cookie schreiben als auf zwei Tafeln gepasst hätten. Obendrein waren Cookies doch immer irgendwie vergleichsweise mühselig.

Demnach war die Web-Developer-Community zunächst sehr begeistert, als etwa 2009 die frohe Botschaft umherging: Es gebe Browser, die nun auch weitere Möglichkeiten zur strukturierten Datenhaltung anböten. Damals recht euphorisch erwartet war „WebSQL“ [5]. Mit WebSQL sollte man nun endlich einen Data Store im Browser haben, der relational strukturiert und mit einer Art SQL ansprechbar sei.

Der Standard wird zwar auch heute noch von Browsern implementiert, aber dennoch vom W3C nicht mehr fortgeführt [6]. Keine gute Ausgangssituation also, um sich dieses Feature als technische Last in das eigene Projekt zu holen. Die direkte Alternative zu WebSQL stellt nun IndexedDB dar – eine initial von Oracle geförderte Technologie, die im Gegensatz zu WebSQL auf einen dokumentenbasierten Store setzt. Sprich: Hier gibt es weder Tabellen noch Relationen oder eine Abfragesprache. Die Möglichkeiten hier sind mit Indizes und Transaktionen schon ganz brauchbar, dennoch scheint IndexedDB oftmals etwas sehr schwergewichtig und komplex, um mal eben ein paar Informationen abzulegen, wie Listing 1 beweist.

Listing 1

var dbName = 'archive' + Date.now(); var storeName = 'magazines'; function openLibrary(onSuccess) { var request = indexedDB.open(dbName); // Dieses Event ist lediglich in modernen Browsern verfügbar request.onupgradeneeded = function(evnt) { var db = evnt.target.result; db.createObjectStore(storeName, { keyPath: 'title' }); // Erstelle ein ObjectStore für diese Datenbank var tx = db.transaction(storeName, 'readwrite'); var store = tx.objectStore(storeName); store.put({ title: 'PHPMagazin', author: 'Pascal', createdAt: Date.now() }); store.put({ title: 'JavaMagazin', author: 'Cato', createdAt: Date.now() }); store.put({ title: 'MobileMagazin', author: 'Vanja', createdAt: Date.now() }); }; request.onsuccess = onSuccess; } function readBooklist(db, onComplete) { var tx = db.transaction(storeName, 'readonly'); var store = tx.objectStore(storeName); var entries = []; store.openCursor().onsuccess = function(evnt) { var cursor = evnt.target.result; if (cursor) { console.log('Name for SSN ' + cursor); entries.push(cursor.valü); cursor.continue(); } else { onComplete(entries) } }; } openLibrary(function(evnt) { var db = evnt.srcElement.result; readBooklist(db, function(entries) { console.log('current booklist', entries); }); });

Wer daher nicht mit Kanonenkugeln auf Spatzen schießen und IndexedDB dafür nutzen möchte, vergleichsweise kleine Datenmengen zu speichern, dem steht ebenfalls noch Web Storage mit Local Storage und Session Storage zur Verfügung.

Status quo Browser Storage

So weit in der Theorie. Wie wir es aus der Vergangenheit kennen, sind Freiheit, Heterogenität und Spielraum sowohl Stärken als auch Schwächen des Webs. Aspekte, die Entwicklern jede Menge Leid bescheren oder besondere Freiheiten geben können. Denn allein die Tatsache, dass es alle diese Technologien gibt, bedeutet nicht, dass wir eine im gleichen Maße flächendeckende Verbreitung voraussetzen können (Kasten „Can I use?“).

Can I use?

Wer sicherstellen will, dass der Data Store der Wahl im Zielbrowser funktioniert, dem seien die folgenden Links ans Herz gelegt:

Alte Browserversionen, die ebenfalls noch als Teilchen der „User-Cloud“ in der Landschaft umherschwirren, außen vor gelassen, stellt man dennoch schnell fest, dass die „zeitgenössischen“ Browser im Bereich des Storage teilweise erschreckende Abweichungen zueinander haben. IndexedDB als Quasinachfolger von WebSQL wird von Mobile Safari erst ab iOS 8 unterstützt, vom Internet Explorer erst ab Version 10. Dafür hat WebSQL im Internet Explorer sowieso noch nie funktioniert; in Firefox funktioniert es immerhin seit Version 33. Es ist schlichtweg ein großes Durcheinander.

Lobend zu erwähnen ist allerdings, dass sich die Browserhersteller beim API für Local Storage und Session Storage zunächst sehr einig waren. Das API kann in nahezu allen gängigen Browsern sicher genutzt werden … zumindest für Datenmengen bis 5 MB. Denn je nach Browser kann man maximal 5 MB oder 25 MB an Daten speichern (Abb. 1 und Abb. 2). Abgesehen davon fehlt dem Local Storage eine Möglichkeit, strukturiert nach Daten zu suchen. Im Prinzip ist Local Storage das Memcached [7] im Browser. Hier werden die Inhalte zwar nicht im Arbeitsspeicher gehalten, aber es bietet auch nicht viel mehr als Key-Value-Paare ablegen und wieder abholen zu können (Listing 2).

wilson_pouchdb_1.tif_fmt1.jpgAbb. 1: Speichergrößen auf dem Desktop, Bildquelle: http://www.html5rocks.com/en/tutorials/offline/quota-research/, [8]
wilson_pouchdb_2.tif_fmt1.jpgAbb. 2: … und in mobilen Browsern, Bildquelle: http://www.html5rocks.com/en/tutorials/offline/quota-research/, [9]

Listing 2

// LocalStorage speichert Key-Value-Paare. // Key und Value sind beides Strings. // Ist Value z. B. ein Objekt, wird dieses // vor Speicherung mit toString gewandelt. var profile = { name: 'Frank Nord', email: 'f.nord@test.com' }; var serializedProfile = JSON.stringify(profile); localStorage.setItem('userProfile', serializedProfile); // zu einem späteren Zeitpunkt oder nach Browser-Reload var serializedProfile = localStorage.getItem('userProfile'); var profile = JSON.stringify(serializedProfile);

Flattening the Browser Storage Landscape

So richtig verlässlich sind unsere Möglichkeiten also leider doch nicht. Das ist schade, denn die Intentionen hinter browserbasiertem Storage sind sicherlich sehr gut. Der Status Quo ist allerdings recht unbefriedigend. Rückblickend auf den bisherigen Verlauf neu eingeführter Websta...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang