Progressive Web Apps: Neue FE-Systeme

Manchmal wird die Konnektivität zum Engpass.

In Unternehmensumgebungen gehen wir oft davon aus, dass eine stabile Internetverbindung eine Selbstverständlichkeit ist. Die realen Bedingungen stellen diese Annahme jedoch häufig in Frage und können möglicherweise kritische Geschäftsabläufe stören. In diesem Artikel wird detailliert beschrieben, wie wir ein traditionelles reines Online-ERP-System in ein zuverlässigeres System mit einer robusten, offline-fähigen Lösung umgewandelt haben. Durch die Nutzung browserbasierter Speicherlösungen wie IndexedDB, den Einsatz von Synchronisierungsmechanismen und die Verwendung von Progressive Web Apps (PWA).

Anfangs folgte das System einer traditionellen Client-Server-Architektur, bei der sich die gesamte Geschäftslogik im Backend befand. Obwohl diese Architektur in Umgebungen mit zuverlässiger Konnektivität gut funktioniert, stellte sie mehrere Herausforderungen dar:

• Transaktionsfehler während Netzwerkunterbrechungen
• Verlorene Verkaufschancen bei Ausfällen
• Schlechte Benutzererfahrung mit konstanten Ladezuständen
• Risiko eines Datenverlusts bei kritischen Vorgängen
• Und am wichtigsten: Kundenverlust aufgrund mangelnden schnellen Service.

Als wir dies definierten, mussten wir improvisieren und sehen, wie wir die Dinge verbessern und auch auf Konnektivität verzichten können, da diese anfangs nicht verfügbar war. Wir haben ein Offline-System mit etwas Internetbedarf implementiert und dabei Progressive Web Apps (PWA) verwendet, was effektiv entscheidend ist Geschäftslogik an das Frontend unter Beibehaltung der Datenintegrität und Synchronisierung mit dem zentralen ERP-System.

Einige Kernkomponenten:

IndexedDB: Für die Offline-Datenspeicherung und das Caching haben wir IndexedDB über die Dexie.js-Bibliothek verwendet, um eine robuste, clientseitige Datenbank bereitzustellen, die strukturierte Datenspeicherung unterstützt. Unten finden Sie ein einfaches Beispiel für die Einrichtung einer Datenbank mit Dexie

// Initialize IndexedDB using Dexie.js
import Dexie from 'dexie';

interface LocalUsers{
id:string;
name:string;
role:string;
dob:string;
phone_no:string
}

interface LocalTrx {
id: string;
syncId:string;
created_at:string;
amount:string;
isSynced:boolean;
modified:string;
}

export class ArticleDatabase extends Dexie {
  transaction!: Table<LocalTrx>;
  users!: Table<LocalUsers>;
  constructor(){
    super("articleDB")
    }

this.version(1).stores({
// define the fields you'll like to query by or find items by within the indexDB
    transactions: 'id, date, amount, isSynced',
    users: 'id, name, role'
 });
}
//create the db
export const db=new ArticleDatabase()

// Open the database
db.open().then(() => {
    console.log("Database opened successfully!");
  })
  .catch((error) => {
    console.error("Failed to open database:", error);
  });

// Adding a new transaction to IndexedDB
import db from ../db
async function addTransaction(transaction) {
try {
   const trx = await db.transactions.add(transaction)
   console.log("Trx added", trx)
} catch (err) {
    console.log("Failed creating trx", err)
}
}

Service Worker: Diese fungieren als Proxy zwischen der App und dem Netzwerk und ermöglichen Offline-Funktionalität, indem sie Ressourcen zwischenspeichern und Anfragen abfangen, um sicherzustellen, dass kritische Daten auch während der Trennung zugänglich bleiben.

//service workesr kann einfach eingerichtet werden, neuerdings werden nextJS-Apps standardmäßig mit service workes mit Vite geliefert, Sie können das Vite-PWA-Plugin verwenden
Hintergrundsynchronisierung: Dadurch können wir Daten synchronisieren, sobald das Netzwerk wieder verfügbar ist, um sicherzustellen, dass Transaktionen nicht verloren gehen und Aktualisierungen automatisch vorgenommen werden, sobald die Verbindung wiederhergestellt ist.

Systemarchitekturablauf
Die Architektur wurde in drei Hauptphasen unterteilt: Initialisierung, Transaktionsverarbeitung und Synchronisierung. Das folgende Flussdiagramm zeigt, wie Daten zwischen diesen Phasen fließen.

*Initialisierungsphase *

Wenn das System startet, prüft es die Netzwerkverbindung:

Wenn das Gerät online ist, holt es die neuesten Stammdaten vom Server und aktualisiert die lokale IndexedDB.

Wenn das Gerät offline ist, lädt es Daten aus IndexedDB und stellt so sicher, dass Benutzer ohne Unterbrechung weiterarbeiten können.

Transaktionsverarbeitung

Wenn Benutzer eine neue Transaktion durchführen:

Lokale Daten werden validiert und in IndexedDB gespeichert.

Ein optimistisches UI-Update wird verwendet, um dem Benutzer das Ergebnis sofort anzuzeigen und so ein reibungsloses und reaktionsfähiges Erlebnis zu bieten.

*Synchronisationsphase *

Wenn die Verbindung wiederhergestellt ist:

Daten werden stapelweise mit dem Server synchronisiert, entweder durch manuelles Klicken auf die Synchronisierungsschaltfläche oder nach einem bestimmten Zeitrahmen.

Wenn die Synchronisierung fehlschlägt (z. B. aufgrund einer langsamen Verbindung), wird die Transaktion einer Liste fehlgeschlagener Transaktionen hinzugefügt und später erneut versucht.

Da wir alles im Frontend verwalten, wie abhängig ist unser Service von der Sicherung von Kundeninformationen?

Authentifizierung & Autorisierung
In jedem Unternehmenssystem ist der Schutz vertraulicher Benutzerinformationen von entscheidender Bedeutung. Unsere Lösung stellt sicher, dass:

JWT-basierte Authentifizierung wird für sichere Benutzersitzungen verwendet.

Rollenbasierte Zugriffskontrolle stellt sicher, dass nur autorisierte Benutzer bestimmte Aktionen ausführen können.

Sichere Token-Speicherung wird mit browserbasierten Mechanismen wie localStorage für zusätzliche Sicherheit gehandhabt.

Um die Risiken der Verwendung lokal gespeicherter Token zu mindern, gehen wir wie folgt vor:

Sicheres Entfernen von Benutzertokens beim Abmelden auslösen.

Stellen Sie sicher, dass sensible Daten aus IndexedDB gelöscht werden, wenn die Sitzung endet oder wenn sich der Benutzer vom System abmeldet. Hinweis: Wenn Transaktionen nicht synchronisiert bleiben, zeigen wir dies dem angemeldeten Benutzer an und erzwingen eine Synchronisierung, bevor er sich abmeldet.

Datenintegrität und Konfliktlösung

Das Synchronisieren von Daten zwischen Client und Server führt zu potenziellen Problemen mit der Datenintegrität, insbesondere wenn mehrere Geräte oder Benutzer offline Änderungen an denselben Daten vornehmen. Um dies zu beheben:

Wir validieren alle Transaktionsdetails (z. B. Mengen, Beträge) vor der Synchronisierung, um sicherzustellen, dass es keine Diskrepanzen gibt.

Wir weisen jeder Transaktion eindeutige IDs zu, um Duplikate während der Synchronisierung zu verhindern.

Konfliktlösungsstrategien werden eingesetzt, um Situationen zu bewältigen, in denen Datenänderungen auf mehreren Geräten offline vorgenommen werden. Wir verwenden beispielsweise einen Zeitstempelansatz.

//Wir versuchen sicherzustellen, dass der Offline-Bereich zuerst berücksichtigt wird, da er der wichtige Teil des Systems ist.

// Initialize IndexedDB using Dexie.js
import Dexie from 'dexie';

interface LocalUsers{
id:string;
name:string;
role:string;
dob:string;
phone_no:string
}

interface LocalTrx {
id: string;
syncId:string;
created_at:string;
amount:string;
isSynced:boolean;
modified:string;
}

export class ArticleDatabase extends Dexie {
  transaction!: Table<LocalTrx>;
  users!: Table<LocalUsers>;
  constructor(){
    super("articleDB")
    }

this.version(1).stores({
// define the fields you'll like to query by or find items by within the indexDB
    transactions: 'id, date, amount, isSynced',
    users: 'id, name, role'
 });
}
//create the db
export const db=new ArticleDatabase()

// Open the database
db.open().then(() => {
    console.log("Database opened successfully!");
  })
  .catch((error) => {
    console.error("Failed to open database:", error);
  });

// Adding a new transaction to IndexedDB
import db from ../db
async function addTransaction(transaction) {
try {
   const trx = await db.transactions.add(transaction)
   console.log("Trx added", trx)
} catch (err) {
    console.log("Failed creating trx", err)
}
}

Netzwerksicherheit
Da die Daten über das Netzwerk übertragen werden, sobald die Verbindung wiederhergestellt ist, haben wir Folgendes sichergestellt:

Ratenbegrenzung, um Missbrauch zu verhindern und sicherzustellen, dass zu viele Anfragen den Server nicht mit einer 429-Antwort überfordern, weshalb wir ursprünglich mit Batch-Updates gearbeitet haben.

Verschlüsselung der Daten während der Übertragung mittels SSL/TLS.

Token-Ablauf und sichere Token-Verwaltung stellen sicher, dass veraltete oder abgelaufene Token automatisch aus dem clientseitigen Speicher entfernt werden.

Alternativen zu PWA und IndexedDB

Während IndexedDB eine gute Wahl für die clientseitige Datenspeicherung in PWAs ist, stehen je nach Komplexität und Anforderungen der Anwendung auch andere Optionen zur Verfügung:

SQLite über WebAssembly (WASM): Einige Entwickler entscheiden sich für die Verwendung von SQLite über WASM für eine erweiterte Datenverwaltung, insbesondere beim Umgang mit größeren Datensätzen oder komplexen Abfragen. Die Integration von SQLite über WASM bringt jedoch zusätzliche Komplexität mit sich, wie z. B. Leistungsbedenken und Browserkompatibilität (z. B. Wie SQLite Notion schneller machte).

Web Storage API (localStorage/sessionStorage): Für einfachere Anwendungen, die keine komplexen Abfragen oder große Datensätze erfordern, kann die Web Storage API eine praktikable Alternative sein. Es ist einfacher zu implementieren, weist jedoch Einschränkungen hinsichtlich der Speicherkapazität und der Abfragefunktionen auf.

Ein Blick in die Zukunft: Zukünftige Trends bei PWA

Mit der Weiterentwicklung der Webtechnologien entwickeln sich auch die Möglichkeiten für Anwendungen wie diese weiter. Zu den aufkommenden Trends gehören:

• WebAssembly und SQLite
• Edge Computing
• Erweiterte Synchronisierungsprotokolle: Neue Protokolle wie CRDTs (Conflict-Free Replicated Data Types) und DeltaSync

Ich selbst kann es kaum erwarten zu erkunden, wie diese Technologien die Landschaft der Offline- und verteilten Anwendungen verändern werden. Durch die rasanten Fortschritte bei leistungsstarken Maschinen und Laptops haben wir die Möglichkeit, diese erhöhte Rechenleistung zu nutzen, um den Benutzern noch anspruchsvollere und effizientere Software bereitzustellen. Gleichzeitig dürfen wir nicht vergessen, wie wichtig es ist, auf mobile Geräte und weniger leistungsstarke Geräte einzugehen und sicherzustellen, dass unsere Lösungen auf allen Plattformen zugänglich und optimiert sind. Das Potenzial ist enorm und ich freue mich darauf, die Grenzen dessen, was mit PWAs möglich ist, weiter zu erweitern.

Hinweis: Was kommt als nächstes?

Wir werden die Dinge in Angriff nehmen. Mit Djuix.io als Backend und React/Angular als Frontend würden wir einen richtigen Grundablauf implementieren. Seien Sie gespannt auf weitere Updates, während wir unseren Ansatz zur Entwicklung fantastischer Apps weiter verbessern.

Wie auch immer, ich hoffe, dass es Ihnen gefallen hat und Sie etwas Neues gelernt haben. Das habe ich auf jeden Fall getan. Ich würde auch gerne Ihre Gedanken und Erfahrungen hören.

Bis dahin.

Das obige ist der detaillierte Inhalt vonProgressive Web Apps: Neue FE-Systeme. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!