Echtzeit-Synchronisation für Web-Apps: Von HTTP zu Reactive Backends

Das HTTP-Problem: Request-Response ist nicht Echtzeit  

Browser kommunizieren über HTTP mit Servern. Dieses Protokoll ist seit 1991 die Grundlage des Internets – wurde aber nie für Echtzeit-Anwendungen entwickelt.

HTTP basiert auf einem einfachen Prinzip: Request-Response.

1. Browser fragt: "Gib mir diese Daten"
2. Server antwortet: "Hier sind die Daten"
3. Verbindung wird beendet

Warum ist das problematisch?  

HTTP wurde für den ersten Fall entwickelt (statische Inhalte für Einzelnutzer). Für den zweiten Fall (kollaborative Echtzeit-Apps) versagt es fundamental.

Die fundamentalen HTTP-Einschränkungen:

1. Einweg-Kommunikation: Nur der Client kann Anfragen initiieren, nie der Server
2. Request-Response-Paradigma: Jede Interaktion muss vom Client gestartet werden (auch bei Keep-Alive-Verbindungen)
3. Keine Server-Push-Benachrichtigungen: Der Server kann nicht aktiv sagen "Hey, hier gibt es Updates!"
4. Polling notwendig: Der Browser muss ständig nachfragen, ob es Änderungen gibt

Inhaltsverzeichnis  

Ein Alltagsbeispiel: Die Einkaufsliste  

Situation: Sie und Ihr Partner haben beide eine Einkaufsliste auf Papier.

Ergebnis: Sie haben jetzt doppelt Milch, weil Ihre Listen nicht synchronisiert waren.

Genau dieses Problem haben Apps mit HTTP!

Das gleiche Problem bei Apps  

Die drei Hauptprobleme  

Wie lösen Entwickler dieses Problem heute?  

Entwickler nutzen drei Tricks, um HTTP trotzdem für Echtzeit-Apps einzusetzen. Alle drei erfordern erheblichen Implementierungsaufwand:

// Der Browser fragt alle 5 Sekunden nach neuen Daten
setInterval(async () => {
const response = await fetch('/api/project/status')
const data = await response.json()
updateUI(data)
}, 5000) // Alle 5 Sekunden

Das Kernproblem  

Alle drei Lösungen sind nur Notlösungen. Entwickler verbringen viel Zeit damit, die Schwächen von HTTP zu kompensieren, statt neue Features für die App zu entwickeln.

Die Lösung: Reaktive Backends  

Das neue Prinzip: Automatische Updates  

Stellen Sie sich vor, Sie haben eine gemeinsame Einkaufsliste auf dem Smartphone. Ihr Partner streicht "Milch" durch – und sofort sehen Sie auf Ihrem Handy die Änderung. Sie müssen nicht nachfragen, es passiert automatisch!

So funktioniert es – Beispiel: Gemeinsame Einkaufsliste  

1. Sie öffnen die App und sehen die gemeinsame Einkaufsliste
2. Der Server merkt sich: "Diese Person schaut auf die Einkaufsliste"
3. Ihr Partner streicht "Milch" durch: Der Server schickt Ihnen automatisch die Änderung
4. Ihre App aktualisiert die Liste von selbst – Sie sehen sofort die durchgestrichene Milch

Convex: Ein praktisches Beispiel  

Convex hat drei wichtige Funktionen:

1. Automatisches Merken (Reactive Queries) – der Server weiß, wer welche Daten braucht
2. Alles oder Nichts (Transactional Mutations) – Änderungen sind garantiert vollständig
3. Immer verbunden (Real-time Subscriptions) – dauerhafte Verbindung ohne Programmieraufwand

Funktion 1: Automatisches Merken (Reactive Queries)  

Das Problem: Der Server muss wissen, wem er Bescheid sagen soll, wenn sich was ändert.

Die Lösung: Convex merkt sich automatisch, wer welche Daten anschaut.

Zurück zur Einkaufsliste: Wenn Sie und Ihr Partner die gemeinsame Liste öffnen, merkt sich der Server automatisch, wer sie anschaut – und wenn jemand "Milch" durchstreicht, werden nur diese beiden Browser informiert und aktualisiert, nicht alle anderen Nutzer der App.

Code-Beispiel  

// Convex Query: Automatisches Tracking
export const getShoppingList = query({
args: { listId: v.id("shoppingLists") },
handler: async (ctx, { listId }) => {
  // Convex merkt sich automatisch:
  // "Dieser Browser schaut auf diese Einkaufsliste"
  const list = await ctx.db.get(listId)
  return list
},
})

// Im Browser: Automatische Updates
const shoppingList = useQuery(api.lists.getShoppingList, { listId })
// Wenn jemand "Milch" durchstreicht, aktualisiert sich die Anzeige automatisch!

Funktion 2: Alles oder Nichts (Transactional Mutations)  

Das Problem: Was passiert, wenn mitten in einer Änderung etwas schiefgeht?

Die Lösung: Bei Convex gilt: Entweder klappt alles, oder gar nichts.

Beispiel aus dem Alltag:

Stellen Sie sich eine Geldüberweisung vor:

1. Geld von Konto A abbuchen
2. Geld auf Konto B einzahlen

Was wäre schlimm? Wenn Schritt 1 klappt, aber Schritt 2 nicht. Dann ist das Geld weg!

Atomare Transaktion bedeutet:

• Entweder passieren BEIDE Schritte
• Oder KEINER der beiden Schritte
• Nie nur einer!

Code-Beispiel  

// Convex Mutation: Alles oder Nichts
export const checkOffItem = mutation({
args: { 
  listId: v.id("shoppingLists"),
  itemName: v.string(),
},
handler: async (ctx, { listId, itemName }) => {
  // Alles zusammen ist eine atomare Transaktion
  const list = await ctx.db.get(listId)
  
  if (!list) {
    throw new Error("Einkaufsliste nicht gefunden")
  }
  
  // Item finden

Die vier Garantien (ACID-Prinzip):

• Atomicity (Unteilbar): Alles oder nichts
• Consistency (Konsistent): Daten bleiben immer gültig
• Isolation (Isoliert): Gleichzeitige Änderungen stören sich nicht
• Durability (Dauerhaft): Erfolgreiche Änderungen sind permanent gespeichert

Funktion 3: Immer verbunden (Real-time Subscriptions)  

Das Problem: Wie kann der Server Sie sofort informieren, wenn sich was ändert?

Die Lösung: Convex hält eine dauerhafte Verbindung offen (wie ein Telefonat).

Das Geniale an Convex: Sie müssen sich um WebSockets nicht kümmern!

Convex richtet die offene Verbindung automatisch ein. Sie programmieren Ihre App normal, und Updates kommen automatisch.

Code-Beispiel  

// Das müssen Sie schreiben (sehr einfach!):
import { ConvexProvider, ConvexReactClient } from 'convex/react'

const convex = new ConvexReactClient(process.env.NEXT_PUBLIC_CONVEX_URL!)

function App() {
return (
  <ConvexProvider client={convex}>
    {/* Alle Komponenten hier bekommen automatische Updates */}
    <ShoppingListApp />
  </ConvexProvider>
)
}

// In Ihrer Komponente: Ganz normal Daten abfragen

Sie müssen NICHTS programmieren für:

• WebSocket-Verbindung aufbauen
• Verbindung überwachen
• Neu verbinden bei Abbruch
• Updates empfangen
• Anzeige aktualisieren

Convex macht alles automatisch!

Vergleich: Alt gegen Neu  

Schauen wir uns die Unterschiede in einer Tabelle an:

Self-Hosting und Data Sovereignty  

Convex bietet neben der verwalteten Cloud-Infrastruktur auch Self-Hosting-Optionen für Unternehmen mit spezifischen Compliance-, Datenschutz- oder Governance-Anforderungen.

Das Open-Source-Backend kann in eigener Infrastruktur betrieben werden. Besonders für regulierte Branchen und DSGVO-konforme Architekturen ist die vollständige Kontrolle über die Dateninfrastruktur entscheidend.

Feature-Umfang: Das Open-Source-Backend enthält alle Core-Features (Queries, Mutations, Actions, Realtime-Subscriptions, Transaktionen).

DSGVO-Überlegungen bei Managed Cloud: Convex ist ein US-Unternehmen. Bei Nutzung der gehosteten Cloud-Lösung liegt eine Drittlandübermittlung vor, die einen Auftragsverarbeitungsvertrag (AVV) und Prüfung der Standardvertragsklauseln (Art. 46 DSGVO) erfordert. Für viele Anwendungen ist dies völlig ausreichend – kritisch wird es nur bei hochsensiblen Daten (Gesundheitsdaten, Finanzdaten) oder wenn Behörden/regulierte Branchen strikte On-Premise-Anforderungen haben.

Empfehlung: Für die meisten Web-Apps (B2B-SaaS, Content-Plattformen, E-Commerce) ist die Managed Cloud mit AVV DSGVO-konform nutzbar. Self-Hosting lohnt sich primär für: Banking/Healthcare, Behörden, Unternehmen mit expliziter On-Premise-Policy.

Der Umstieg: Von alt zu neu  

Wie kompliziert ist die Umstellung?  

Gute Nachricht: Sie müssen nicht alles auf einmal ändern. Sie können Schritt für Schritt umsteigen.

Schauen wir uns ein Beispiel an: Wie viel einfacher wird der Code?

Vorher: Mit dem alten System (HTTP)  

Was ist hier das Problem?

Code-Beispiel  

// Altes System: Viel zu kompliziert!
// Backend (Express.js)
app.get('/api/projects/:id', async (req, res) => {
const project = await db.projects.findById(req.params.id)
res.json(project)
})

app.patch('/api/projects/:id', async (req, res) => {
const updated = await db.projects.update(req.params.id, req.body)
res.json(updated)
})

// Frontend (React + Redux)
const ProjectView = ({ projectId }) => {
const dispatch = useDispatch()

Nachher: Mit Convex (viel einfacher!)  

Der Unterschied ist riesig!

Kurz gesagt: Statt Hunderte Zeilen Code zu schreiben, nutzen Sie useQuery und useMutation. Den Rest übernimmt Convex.

Code-Beispiel  

// Convex Backend (viel einfacher!)
export const getShoppingList = query({
args: { listId: v.id("shoppingLists") },
handler: async (ctx, { listId }) => {
  // Einfach Daten holen - Convex merkt sich automatisch,
  // wer diese Liste anschaut
  return await ctx.db.get(listId)
},
})

export const checkOffItem = mutation({
args: { 
  listId: v.id("shoppingLists"),
  itemName: v.string(),
},

Geschwindigkeits-Vergleich (mit Zahlen!)  

Stellen Sie sich vor: 1.000 Personen nutzen Ihre App gleichzeitig.

Einschränkungen und Grenzen  

Internet-Verbindung erforderlich  

Reaktive Backends benötigen eine aktive Verbindung zum Server. Offline-first-Apps erfordern zusätzliche Architektur (lokales Caching, Sync-Konflikte).

Migrations-Aufwand  

Bestehende Systeme erfordern Refactoring. Empfohlen ist eine inkrementelle Migration.

Offline-Support: Hybride Lösungen mit lokalem State-Management (LocalStorage, IndexedDB) und Sync-on-Reconnect sind möglich, erfordern aber zusätzliche Implementierung.

Fazit und Empfehlung  

Unsere Einschätzung: Für Echtzeit-Anwendungen sind reaktive Backends notwendig. Die Frage lautet nicht "ob", sondern "wann" Sie umsteigen.

Weiterführende Links  

• Convex Dokumentation – Offizielle Dokumentation mit Tutorials und Beispielen. Es gibt eine kostenlose Version zum Testen.
• The Reactive Manifesto – Grundprinzipien reaktiver Systeme (etwas technisch, aber gut erklärt).
• RFC 6455: WebSocket Protocol – Die offizielle technische Spezifikation für WebSockets (für Experten).