Echtzeit-Synchronisation für Web-Apps: Von HTTP zu Reactive Backends
Apps wie Google Docs oder Figma synchronisieren Änderungen in Echtzeit – ohne dass Sie auf "Aktualisieren" klicken müssen. HTTP wurde nie für Echtzeit-Apps gebaut. Dieser Artikel erklärt, warum traditionelle Backend-Systeme bei kollaborativen Anwendungen versagen – und wie reaktive Backends das Problem lösen.
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.
- Browser fragt: "Gib mir diese Daten"
- Server antwortet: "Hier sind die Daten"
- Verbindung wird beendet
Warum ist das problematisch?
| Feature | Früher (1990er) | Heute |
|---|---|---|
| Anwendungsfall | Statische Inhalte lesen | Gemeinsam Inhalte bearbeiten |
| Interaktion | Einzelnutzer, keine Echtzeit-Updates | Mehrere Nutzer bearbeiten gleichzeitig |
| Entwickelt für | ✓ HTTP wurde dafür entwickelt | ✗ HTTP versagt hier fundamental |
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:
- Einweg-Kommunikation: Nur der Client kann Anfragen initiieren, nie der Server
- Request-Response-Paradigma: Jede Interaktion muss vom Client gestartet werden (auch bei Keep-Alive-Verbindungen)
- Keine Server-Push-Benachrichtigungen: Der Server kann nicht aktiv sagen "Hey, hier gibt es Updates!"
- Polling notwendig: Der Browser muss ständig nachfragen, ob es Änderungen gibt
Seit HTTP/1.1 (1997) bleiben Verbindungen standardmäßig offen (Keep-Alive). Das spart Zeit beim Verbindungsaufbau, löst aber nicht das fundamentale Problem: Der Server kann trotzdem keine Nachrichten initiieren. Es ist immer noch Request-Response – nur über eine bestehende Verbindung.
HTTP ist Pull (Sie fragen nach). Echtzeit-Apps brauchen Push (der Server informiert Sie).
Ein Alltagsbeispiel: Die Einkaufsliste
Situation: Sie und Ihr Partner haben beide eine Einkaufsliste auf Papier.
Sie schauen auf Ihre Liste
Ihr Partner kauft die Milch
Sie kaufen AUCH Milch
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
1. Alte Daten
Sie sehen nicht, dass Ihr Partner die Milch bereits gekauft hat. Beide arbeiten mit unterschiedlichen Listen.
2. Keine automatische Info
Der Server kann nicht sagen: "Achtung, die Milch wurde gestrichen!" Sie müssen die App selbst neu laden, um Updates zu sehen.
3. Gleichzeitige Änderungen
Was passiert, wenn beide gleichzeitig einen Artikel streichen? Eine Änderung geht verloren. Das nennt man eine "Race Condition" – wie ein Wettrennen, bei dem nur einer gewinnen kann.
Wie lösen Entwickler dieses Problem heute?
Entwickler verwenden drei Tricks, um HTTP trotzdem zu nutzen und damit Browser verwenden zu können. Aber alle drei sind kompliziert:
Fachbegriff: Polling
Technisch: setInterval() + fetch() – Der Browser fragt in regelmäßigen Abständen nach Updates.
So funktioniert es
Der Browser sendet automatisch alle paar Sekunden eine Anfrage: "Gibt es Neuigkeiten?"
Beispiel aus dem Alltag
Stellen Sie sich vor, Sie schauen alle 5 Sekunden auf Ihr Smartphone, um zu prüfen, ob eine neue Nachricht angekommen ist.
Code:
// 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 SekundenProbleme:
- Verschwendung: Der Browser fragt auch, wenn sich nichts geändert hat
- Verzögerung: Änderungen sehen Sie erst beim nächsten Nachfragen (bis zu 5 Sekunden später)
- Server-Belastung: 1000 Nutzer = 1000 Anfragen alle 5 Sekunden
Das eigentliche Problem
Alle drei Lösungen sind nur Notlösungen. Entwickler verbringen viel Zeit damit, die Schwächen von HTTP zu reparieren, statt neue Features und Funktionalität für die eigentliche 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!
| Feature | HTTP (altes System) | Reaktive Backends (neues System) |
|---|---|---|
| Daten-Updates | Sie müssen ständig fragen: "Gibt es was Neues?" | Der Server informiert Sie automatisch bei Änderungen |
| Analogie | Alle 5 Sekunden Briefkasten öffnen | Push-Benachrichtigung auf dem Handy |
| Einkaufsliste | Doppelt Milch gekauft | Automatisch synchronisiert |
So funktioniert es – Beispiel: Gemeinsame Einkaufsliste
- Sie öffnen die App und sehen die gemeinsame Einkaufsliste
- Der Server merkt sich: "Diese Person schaut auf die Einkaufsliste"
- Ihr Partner streicht "Milch" durch: Der Server schickt Ihnen automatisch die Änderung
- Ihre App aktualisiert die Liste von selbst – Sie sehen sofort die durchgestrichene Milch
Convex: Ein praktisches Beispiel
Klick lädt YouTube (Datenschutz)
Convex ist ein Backend-System, das reaktive Updates automatisch macht.
Einfach gesagt: Convex kümmert sich um alle komplizierten Dinge (Synchronisation, Updates, etc.). Sie programmieren nur Ihre eigentliche App.
Convex hat drei wichtige Funktionen:
- Automatisches Merken (Reactive Queries) – der Server weiß, wer welche Daten braucht
- Alles oder Nichts (Transactional Mutations) – Änderungen sind garantiert vollständig
- 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!Effizient: Nur die Browser, die die Einkaufsliste offen haben, bekommen Updates.
Kein Code nötig: Sie müssen nichts programmieren - Convex macht es automatisch.
Genau: Wenn Ihr Partner "Milch" durchstreicht, werden nur Sie und andere Personen mit dieser Liste informiert – nicht Personen mit anderen Listen.
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:
- Geld von Konto A abbuchen
- 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!
Keine kaputten Daten: Sie haben nie "halbe" Änderungen in Ihrer Datenbank.
Sicher: Wenn etwas schiefgeht, wird alles automatisch rückgängig gemacht.
Automatisch: Sie müssen nichts programmieren - Convex macht es von selbst.
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 findenDie 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 abfragenSie müssen NICHTS programmieren für:
- WebSocket-Verbindung aufbauen
- Verbindung überwachen
- Neu verbinden bei Abbruch
- Updates empfangen
- Anzeige aktualisieren
Convex macht alles automatisch!
Bei normalen WebSockets: Sie müssen Hunderte Zeilen Code schreiben (Verbindung aufbauen, Abbrüche behandeln, Updates verarbeiten, etc.)
Bei Convex: Sie schreiben 2 Zeilen Code (useQuery und fertig). Den Rest macht Convex automatisch.
Zeitersparnis: Tage oder Wochen Arbeit werden zu Minuten!
Vergleich: Alt gegen Neu
Schauen wir uns die Unterschiede in einer Tabelle an:
| Feature | Traditionelles HTTP | Reaktive Backend (Convex) |
|---|---|---|
| Datenkonsistenz | Manuell | Automatisch |
| State Management | Client-seitig | Backend-gesteuert |
| Echtzeit-Updates | Polling/WebSocket | Native Reaktivität |
| Cache-Invalidierung | Manuell | Automatisch |
| Transaktionale Sicherheit | Anwendungslogik | Plattform-garantiert |
| Development Complexity | Hoch | Niedrig |
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).
| Feature | Convex Self-Hosted Open-Source | Convex Managed Cloud |
|---|---|---|
| Queries, Mutations, Actions, Transaktionen | Identische Funktionalität | Identische Funktionalität |
| Realtime Subscriptions | Identische Funktionalität | Identische Funktionalität |
| Convex Dashboard | Enthalten (vom Nutzer gehostet & verwaltet) | Enthalten (vom Anbieter gehostet & verwaltet) |
| Streaming Import/Export | Manuell über npx convex export/import | Verwaltete Konnektoren (Fivetran, Airbyte) |
| Log-Aggregation & -Streaming | Benutzerdefinierte Lösung (z.B. Loki, ELK) | Integriertes Log-Streaming (Axiom, Datadog) |
| Exception Monitoring | Benutzerdefinierte Lösung (z.B. selbstgehostetes Sentry) | Integrierte Sentry-Unterstützung |
| Health & Insights Dashboard | Benutzerdefinierte Lösung (z.B. Grafana, Prometheus) | Integriertes Dashboard |
| Automatisierte Backups | Benutzerdefinierte Skripte (z.B. convex-self-hosted-backups in S3) | Automatisierte Backups (täglich/wöchentlich) |
| Point-in-Time Restore | Manueller Prozess (aus verfügbaren Backups) | Verwaltete Point-in-Time-Wiederherstellung |
| Disaster Recovery | Volle Verantwortung des Nutzers (Multi-Region-Setup) | Von Convex verwaltet |
| Horizontale Skalierung | Standardmäßig Single-Node (erfordert Code-Modifikation) | Automatische, verwaltete Skalierung |
| Offizieller Support & SLA | Nur Community (Discord, GitHub Issues) | E-Mail & Priority Support (mit SLAs im Pro Plan) |
| Zertifizierungen | Verantwortung des Nutzers (eigene Infrastruktur zertifizieren) | SOC 2, HIPAA, GDPR (verifizierte Plattform) |
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?
Über 50 Zeilen Code nur für eine einfache Anzeige
Ständige Anfragen alle 5 Sekunden (auch wenn sich nichts ändert!)
Kompliziert: Fehlerbehandlung, Rollback, etc. muss alles manuell programmiert werden
Unsicher: Kann trotzdem zu Problemen führen
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!
70% weniger Code (15 Zeilen statt 50!)
Keine ständigen Anfragen mehr (kein Polling)
Automatisch sicher (atomare Transaktionen)
Fehlerbehandlung eingebaut (Sie müssen nichts programmieren)
Immer synchron: Alle Browser sehen garantiert dieselben Daten
Einfach gesagt: Statt Hunderte Zeilen komplizierter Code zu schreiben, nutzen Sie einfach useQuery und useMutation. Den Rest macht Convex automatisch!
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.
99,9% weniger Anfragen an den Server!
50x schneller (von 5 Sekunden auf 0,1 Sekunden)
Viel günstiger (weniger Server-Kosten)
Einschränkungen und Grenzen
Internet-Verbindung erforderlich
Reaktive Backends benötigen eine aktive Verbindung zum Server. Für Offline-first-Apps bedeutet das zusätzliche Komplexität (lokales Caching, Sync-Konflikte).
Reaktive Systeme sind primär für Online-Anwendungen konzipiert. Offline-Funktionalität erfordert zusätzliche Architektur-Layer (lokale Replikation, Conflict Resolution).
Migrations-Aufwand
Bestehende Systeme erfordern Refactoring. Die empfohlene Strategie: Inkrementelle Migration.
Strangler Fig Pattern: Neue Features mit Convex, Legacy-System parallel betreiben, schrittweise Migration.
Vorteile: Kein Big-Bang-Risiko, kontinuierliche Wertschöpfung, Rollback-Möglichkeit jederzeit.
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
JA: Echtzeit-Apps, kollaborative Tools, moderne Web-Apps
NEIN: Reine Offline-Apps, einfache statische Websites
Unsere Meinung: Für Echtzeit-Anwendungen sind reaktive Backends nicht optional – sie sind notwendig. Die Frage ist 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).
Kontaktieren Sie uns für ein unverbindliches Gespräch.
E-Mail: office@webconsulting.at