← React / TypeScript

React / TypeScript · 18 / 18

Gemeinsame Bearbeitung mit WebSockets und PostgreSQL

Du verstehst geordnete Operationen, Wiederverbindung und die Rolle eines dauerhaften Operationslogs.

  • Groß
  • Anspruchsvoll
  • 120 min

Voraussetzungen: Persistente Optimistic UI, Replay und Konflikte

Eine gemeinsame Oberfläche benötigt mehr als einen offenen WebSocket. Clients müssen erkennen, welche Änderungen der Server bestätigt hat und welche nach einer Unterbrechung fehlen. Realtime Collaboration Lab hält die dauerhafte Reihenfolge in PostgreSQL. Ein WebSocket verteilt Nachrichten. LISTEN/NOTIFY signalisiert Änderungen, speichert sie aber nicht dauerhaft. Wir beginnen mit einer ausführbaren kleinen Sequenzprüfung und verfolgen danach denselben Ablauf im vollständigen Projekt.

Beispieldateien

01Die Reihenfolge lokal nachvollziehen

Der Lernclient hält lastSequence und Textzustand. Eine Operation mit bereits bekannter Sequenz wird nicht doppelt angewendet. Eine Lücke erzeugt einen ausdrücklich sichtbaren Fehler. Der Simulator stellt keine WebSocket-Verbindung her, sondern isoliert diese eine Regel.

sequence.mjs · javascriptDatei öffnen
class ClientState {
  sequence = 0;
  title = '';
  apply(operation) {
    if (operation.sequence <= this.sequence) return;
    if (operation.sequence !== this.sequence + 1) throw new Error('Sequence gap: request recovery');
    this.title = operation.title; this.sequence = operation.sequence;
  }
  snapshot(value) { this.sequence = value.sequence; this.title = value.title; }
}
const client = new ClientState();
client.apply({ sequence: 1, title: 'First' });
client.apply({ sequence: 1, title: 'First' });
try { client.apply({ sequence: 3, title: 'Third' }); }
catch (error) { console.log(error.message); }
client.snapshot({ sequence: 3, title: 'Third' });
client.apply({ sequence: 4, title: 'Fourth' });
console.log(client.sequence, client.title);

Starten / prüfen

node sequence.mjs

02Die vollständige Anwendung aufsetzen

Das Setup klont eine feste öffentliche Codeversion in einen neuen Lernordner. Installiere deren dokumentierte Node.js- und pnpm-Versionen. pnpm verify prüft Code und Unit-Verträge. Starte PostgreSQL anschließend nach dem verlinkten Gateway-Runbook mit einem eigenen lokalen DATABASE_URL.

setup.sh · bashDatei öffnen
git clone https://github.com/wasiliy-strecker/realtime-collaboration-lab.git realtime-collaboration-lab-learning
cd realtime-collaboration-lab-learning
git checkout f42a832c68c2ee750b37c3b5de6e1fc0fddcc90c
corepack pnpm install --frozen-lockfile
corepack pnpm verify

03Eine Operation durch den Server verfolgen

Lies collaboration.ts und postgres/store.ts. Der Server prüft den Vertrag und führt die dauerhafte Änderung in einer Transaktion aus. Erst nach erfolgreicher Speicherung darf die Operation als bestätigt verteilt werden. Presence ist dagegen vorübergehend und kein Ersatz für gespeicherte Fachinformationen.

04Nach einer Unterbrechung aufholen

Ein Client meldet seinen bestätigten Stand. Der Server liefert fehlende Operationen oder einen passenden Snapshot. Eine Nachricht allein macht keinen vollständigen Stand. Im Simulator ersetzt Snapshot 3 die fehlende Folge, bevor Sequenz 4 angewendet wird.

05Konflikte und Duplikate unterscheiden

Eine wiederholte Operation ist nicht automatisch ein neuer Benutzerwunsch. Stabile IDs helfen, dieselbe Absicht wiederzuerkennen. Gleichzeitig müssen widersprechende Änderungen fachlich entschieden werden. Eine lückenlose Sequenz definiert Reihenfolge, aber noch keine universelle Konfliktlösung.

06Mehrere Clients und Fehlerfälle testen

Starte pnpm dev:gateway und pnpm dev:web in getrennten Terminals gemäß README. Öffne zwei Browserfenster. Ändere einen Eintrag, trenne einen Client und verbinde ihn wieder. Die Playwright-Suite prüft solche Szenarien mit echtem Gateway und PostgreSQL. Vergleiche am Ende beide bestätigten Stände.

Erwartetes Ergebnis

Der Simulator erkennt die Lücke, übernimmt Snapshot 3 und erreicht genau einmal Sequenz 4. Im vollständigen Projekt holen Clients fehlende bestätigte Operationen nach.

Datenfluss
  1. React-Absicht
  2. WebSocket-Vertrag
  3. PostgreSQL-Transaktion
  4. Operationslog / Sequenz
  5. Bestätigung / Recovery

Deine Übung

Ergänze im Simulator eine Operation 2 nach dem Snapshot 3. Was muss passieren? Teste außerdem eine verlorene Bestätigung im echten Mehrclientablauf.

Lösung mit Erklärung anzeigen

Operation 2 ist bereits vom Snapshot abgedeckt und wird ignoriert. Bei verlorener Bestätigung muss dieselbe fachliche Operations-ID wiederholt werden. Der Server darf sie nicht erneut als neue Wirkung anwenden. Ein Test prüft sowohl den resultierenden Zustand als auch die bestätigte Sequenz.

Projektbezug und Quellen

Das Beispiel ist zum Lernen vereinfacht. Die verlinkte Codeversion zeigt die Anwendung im Projekt und die dortigen Prüfungen.