Herausforderungen von Offline-fähigen Webanwendungen

Im Rahmen meines letzten Projekts musste ich eine Webanwendung planen, die den Offline-Speicher des Browsers verwendet. In der Theorie sollte ja alles wunderbar funktionieren, doch in der Praxis hatten wir einige harte Nüsse zu knacken. Die wichtigsten Herausforderungen möchte ich hier kurz darstellen.

Im Rahmen meines letzten Projekts musste ich eine Webanwendung planen, die den Offline-Speicher des Browsers verwendet. In der Theorie sollte ja alles wunderbar funktionieren, doch in der Praxis hatten wir einige harte Nüsse zu knacken. Die wichtigsten Herausforderungen möchte ich hier kurz darstellen.

Wahl des “richtigen” Offline-Speichers

Sie haben richtig gelesen, als erstes müssen Sie sich entscheiden, welchen Offline-Speicher Sie verwenden wollen. Es gibt nämlich unterschiedliche Speicherorte, die alle Vor- und Nachteile haben. Die einfachste Art der Speicherung ist der WebStorage (localStorage). Hier können Sie in einer key-value Map beliebige zuvor serialisierte Datenobjekte über einen eindeutigen Schlüssel speichern. Dieser Speicher ist einfach zu benutzen, allerdings hat er einige Einschränkungen. Obwohl diesen Speicher jeder Browser unterstützt, ist er limitiert in seiner Größe. Manche Browser können zwar die Speichergröße über 5 MB anheben. Der Nachteil hier ist allerdings die sinkende Performance der Zugriffe, speziell bei größeren Objekten.

IndexedDB bietet einen größeren, unlimitierten Speicherplatz mit einer hierarchischen key/value Persistierung und einer Basisindizierung. Diese Speicherquelle wird aber noch nicht auf allen Browsern unterstützt und bietet leider auch noch keinen SQL-Zugriff.

Für SQL-Fans ideal ist die Verfügbarkeit der bekannten Abfragesprache in WebSQL Database. Allerdings ist dieser Speicherstandard vorerst Chrome-Browsern vorbehalten und daher für viele Projekte nicht geeignet.

Egal für welche Speichermöglichkeit Sie sich entscheiden, Sie müssen jedenfalls die Vor- und Nachteile abwiegen und dann später mit der Entscheidung leben. Ein Umstieg in laufendem Betrieb ist eine eigene Herausforderung, die einer großen Vorbereitung bedarf.

Verschlüsselung der Daten

Sollten Sie sensible Daten in Webbrowsern speichern wollen, so müssen Sie auf jeden Fall eine Verschlüsselung ins Auge fassen. Dabei sind mehrere Aspekte zu planen:

  1. Wahl der Verschlüsselungsmethode:
    Dies hängt in erster Linie auch von der gewünschten Sicherheit ab. Sind die Geräte gehärtet, d.h. ist bei Entwendung der Geräte sichergestellt, dass niemand die Festplatten auslesen kann, ist hier eventuell eine geringere Sicherheit möglich. Ansonsten sollten Sie die höchstmögliche Sicherheitsstufe anstreben.
  2. Eingabe des Ver- und Entschlüsselungskeys
    Die Sicherheit nutzt nichts, wenn der Key im Programmcode hinterlegt wird. Wenn Sie wirklich sicher gehen wollen, müssen Sie hier den User miteinbeziehen, um einen Teil des Schlüssels beim Programmstart einzugeben.
  3. Ebene der Verschlüsselung
    Wollen Sie ganze Datenobjekte verschlüsseln oder nur einzelne Attribute? Diese Entscheidung hängt zu einem großen Teil auch von der Wahl des Offline-Speichers ab, da Sie z.B. beim LocalStorage in der Regel immer ganze Objekte serialisiert abspeichern.

Wahl der Datenstrukturen

In der Entwicklungsphase ändern sich die Datenstrukturen laufend. Dies ist da auch überhaupt kein Problem, da Sie einfach neu deployen und den localStorage mit über die Entwickler-Konsole mit dem Befehl

localStorage.clear();

löschen können.

Aber sobald Ihre Anwendung in Produktion ist, werden Sie mit jeder Änderung der Datenstruktur große Probleme einfahren, weil Sie prüfen müssen, ob die in der alten Version gespeicherten Offline-Daten mit der neuen Version noch lesbar sind.

Bei uns hat sich daher als sinnvoll erwiesen, folgende Maßnahmen zu ergreifen:

  1. eine Generische Datenstruktur, die sich einer Key-Value-Map bedient, kann am einfachsten erweitert werden
  2. eine Serialisierung über JSON ist besser als z.B. die native-GWT-Serialisierung zu verwenden
  3. Weglöschen von nicht mehr benötigten Datenfeldern kann tödlich sein!

 Migrationsaufwand nicht unterschätzen

Sobald eine Anwendung in Produktion ist, sollten Sie sich ein Szenario für die Migration von einer Version auf die nächste überlegen. Nicht zuletzt, um sicher zu stellen, dass die Offline-Daten die Migration überleben, auch um die Kompatibilität der Client-Server-Schnittstellen zu gewährleisten, ist hier ein hoher Testaufwand einzuplanen.