Declarative Offline-First Application Development under the Backend-as-a-Service Paradigm

Geeignet für: Masterarbeit

Backend-as-a-Service (BaaS) ist ein neues Paradigma zur Entwicklung von Apps und Webseiten, bei der ein BaaS-System Datenhaltung und Anwendungslogik als Cloud-Service bereitstellt. “Offline First” ist in der Frontend-Entwicklung ein zunehmend wichtiger Ansatz, um sicherzustellen, dass (Web-)Apps auch ohne bestehende Netzwerkanbindung weiter funktionieren (Beispiel: Gmail). Diese Lösungen sind üblicherweise hochgradig applikationsspezifisch, so dass bei jeder Neuentwicklung erneut der Aufwand zur Offline-Speicherung anfällt. In dieser Arbeit soll ein deklaratives Offline-First (DOF) Storage-Konzept für die JavaScript-API von Orestes konzipiert und implementiert werden.

Ziele:

• Storage: Transparente Speicherung von geladenen Objekten in geeignetem Storage Provider (LocalStorage, IndexedDB, WebSQL, etc.). Vergleich und Auswahl der Technologien.
• Queries: lokale Anfrageverarbeitung als Fallback. Konkret: performante Implementierung von MongoDB-Queries auf lokalen Daten. Siehe z.B.: Sift.js und MiniMongo.
• Storage Policy & SLA: Kontrolle des Offline-Verhaltens durch Policies, die festlegen in welchen Szenarien lokal gespeicherte Daten statt Backend-Daten angefragt werden und wann sie wieder verdrängt werden dürfen und wie sie aktualisiert werden. Idee:
  • DOF-Cache: Speicherung erfolgt lazy wenn Objekt geladen
  • DOF-WorkingSet: Definition von Offline Working Sets über Query, werden beim Seitenaufruf automatisch synchronisiert und optional im Hintergrund über WebSockets aktualisiert. Mögliche Vertiefung: 1) Unterstützung durch Bloomfilter 2) Containment Test: kann Query vollständig lokal ausgewertet werden.
  • DOF-Full: alle (ggf. per-User-)Daten laden.
• Offline Updates: Aktualisierung des lokalen Zustands, setzen von Dirty-Flags. Zu beachtende Fehler-Typen: App-Crashes und Netzwerkabbrüche.
• Synchronisation: Eager (bei jedem Update & bestehender Verbindung), Zeitgesteuert (alle x Sekunden) mit Delay Tolerance und präferiertem Connection Typ (WLAN vs mobile).
• Konfliktauflösung: Handler zur Konfliktauflösung bei nebenläufigen (d.h. konfliktierenden Updates).
• Evaluation: 1) Fall-Studie zu gewähltem Use-Case (z.B. Kalender- oder Todo-Anwendung) 2) Verhaltens-Vergleich mit existierenden BaaS-Offline-APIs (z.B. Parse oder Kinvey), d.h. Untersuchung verschiedener Fehlerszenarien und Vergleich der erzielten Ergebnisse (z.B. Lost Updates).

Einführungsliteratur:

• Backend-as-a-Service Einführung
• IndexedDB
• Web Storage API
• Orestes API

Vertiefungsliteratur:

• Reliable, consistent, and efficient data sync for mobile apps (Paper)
• HTML 5 in Action, Kapitel 5
• Conflict-free Replicated Data Types (Datenstrukturen für automatische Konfliktauflösung)
• Operational Transformation (Anderer Ansatz zur Konfliktauflösung aus dem Bereich Collaborative Editing)