Laden...

Offline App - Distributed State

Erstellt von Campy vor 5 Jahren Letzter Beitrag vor 5 Jahren 1.301 Views
C
Campy Themenstarter:in
439 Beiträge seit 2008
vor 5 Jahren
Offline App - Distributed State

Hallo zusammen,

wir haben vor Jahren eine Anwendung mit ASP.NET WebApi als Dienst und einer WPF Clientanwendung entwickelt.
Nun haben wir alle Abhängigkeiten und Technologien auf den aktuellen Stand gebracht.
Die weitere Planung sieht die Erstellung einer App auf Angular Basis mit Offline-Sync vor.

Nun zu meiner Frage:
Hat jemand von Euch schon eine größere Business-Anwendung Offline-fähig programmiert?
Gibt es bereits Technologien zum mergen auf unserer vorhandenen Basis?

A programmer is just a tool, which converts coffeine into code! 🙂

16.834 Beiträge seit 2008
vor 5 Jahren

Hat jemand von Euch schon eine größere Business-Anwendung Offline-fähig programmiert?

Ja.

Gibt es bereits Technologien zum mergen auf unserer vorhandenen Basis?

Sync ist ja auch immer von der Anwendungslogik und der Datenstruktur abhängig.
Wäre mir neu, wenn es hier was "fertiges" geben würde.

Wenn es Dir um den State allgemein geht, dann schau Dir NGRX an.
Damit kannst Du den gesamten State einer Angular App zentral verwalten (und aktualisieren)

C
Campy Themenstarter:in
439 Beiträge seit 2008
vor 5 Jahren

Ok Abt, darf ich fragen welche DBs / sync mechanisem du in Verwendung hattest oder empfehlen würdest?

Mir ist klar, dass das immer sehr stark von der Logik abhängig ist aber in der sync Schicht gibt es doch bestimmt fertige Frameworks?

A programmer is just a tool, which converts coffeine into code! 🙂

16.834 Beiträge seit 2008
vor 5 Jahren

Also wenn Du erwägst, dass Du direkt eine Datenbank verwendest, die dann mit einem Client kommunziert für die Synchronisation, dann ist das ein grober Konzeptfehler.

Datenbanken - und ja ich kenne die Funktionalitäten einer CouchDB - sollten niemals direkt von Außen erreichbar sein.
Und je nachdem welche Daten Du hast und in welcher Branche Du tätig bist, darfst Du das zumindest in DE auch gesetzlich nicht.
Das wird übrigens auf allen großen Cloud-Plattformen (Azure, AWS, Google Cloud) bei deren PaaS Produkten eben aus Sicherheitsgründen auch technisch unterbunden.

Ein Client muss immer mit einer entsprechenden Schnittstelle für den Datenaustausch kommunizieren, zB einer json-basierten HTTP API.
Alles andere erfüllt in keiner Hinsicht modernen Sicherheitsanforderungen.

Mir ist kein fertiges Framework bekannt. Wir synchronisieren den State durch eine eigene Implementierung auf Basis von NGRX gegen eine Hypermedia JSON API.
Eine Sync-Schicht gibt es nicht. Sync ist einfach nur eine Funktionalität der Datenschicht.
Sync ist nichts anderes als das bi-direktionale statt uni-direktionale Aktualisieren von Daten, und dazu kann man einfach nur WebSockets verwenden.
Keine Raketenwissenschaft. 😃

5.658 Beiträge seit 2006
vor 5 Jahren

Ich hab zwar mit sowas noch keine Erfahrungen gemacht. Aber nach meinem Verständnis muß man zwei Probleme lösen:

  1. Das Abholen der Daten, bevor in den Offline-Modus gewechselt wird.
  2. Das Speichern der geänderten Daten, nachdem in den Online-Modus gewechselt wird.

Die Client-Anwendung muß dafür sorgen, daß die Daten irgendwo im Speicher vorgehalten werden, z.B. in einem Redux-Store oder im HTML Web Storage oder sowas. Und daß zum richtigen Zeitpunkt mit dem Server synchronisiert wird.

Die Web-API bzw. die Server-Anwendung braucht dann nur die entsprechenden Methoden dafür bereitstellen.

Klingt jetzt nicht besonders aufwenig. Die wichtigsten Fragen sind wohl, welche Daten man im Offline-Modus benötigt, und wie man die Änderungen trackt.

Weeks of programming can save you hours of planning

C
Campy Themenstarter:in
439 Beiträge seit 2008
vor 5 Jahren

Hallo zusammen,

ich hatte das denke ich etwas unverständlich geschrieben - wir wollen selbstverständlich die vorhandene REST-API für den Sync verwenden.
Wie du sagtest wäre alles andere ein grober Fehler noch dazu mit der Datenbank.

Zum Zwischenspeichern der Daten dachten wir an WebStorage.

Alles klar - dachte schon, dass es da kein fertiges Konzept gibt dann werden wir das auch selbst implementieren.

Vielen Dank!

A programmer is just a tool, which converts coffeine into code! 🙂