Wie Supabase Realtime funktioniert
Supabase Realtime ist eine WebSocket-basierte Schicht über PostgreSQL, die Änderungen in deiner Datenbank in Echtzeit broadcastet. Wenn eine Zeile in einer Tabelle eingefügt, aktualisiert oder gelöscht wird, empfangen alle abonnierten Clients sofort ein Event, ohne Polling.
Die technische Grundlage: Supabase nutzt PostgreSQLs built-in Logical Replication. Änderungen werden über einen Replication Slot erfasst und an den Realtime-Service weitergegeben, der WebSocket-Events an abonnierte Clients sendet.
Für das WeWeb-Frontend bedeutet das: kein interval-basiertes Polling (setInterval alle 5 Sekunden die Daten neu laden). Stattdessen: einmalige WebSocket-Verbindung, und die UI aktualisiert sich sofort wenn Daten in der Datenbank geändert werden. Für ein Produktions-SaaS mit vielen gleichzeitigen Nutzern ist das deutlich effizienter als Polling, weniger Datenbankbelastung, niedrigere Infrastrukturkosten und bessere UX.
Realtime in WeWeb konfigurieren
In WeWebs Supabase-Plugin: aktiviere Realtime für eine Collection. Das erstellt automatisch einen WebSocket-Kanal für diese Tabelle. Wenn sich Daten in Supabase ändern, aktualisiert sich die Collection in WeWeb sofort, und alle an diese Collection gebundenen UI-Elemente aktualisieren sich mit.
Konfiguriere, welche Events du empfangen möchtest: - INSERT: neue Einträge in der Tabelle - UPDATE: geänderte Einträge - DELETE: gelöschte Einträge - ALL: alle Events
Für ein Dashboard, das neue Bestellungen oder Alerts zeigt: aktiviere INSERT und UPDATE. DELETE brauchst du meist nicht. Weniger Events = weniger WebSocket-Traffic = niedrigere Kosten.
Row-Level-Security funktioniert auch mit Realtime: Nutzer empfangen nur Realtime-Events für Zeilen, auf die ihre RLS-Policy Zugriff gibt. Das ist entscheidend für Multi-Tenant-Apps, bei denen Nutzer nur ihre eigenen Daten sehen dürfen.
Dashboard-Layout für Echtzeit-Daten
Das optimale Dashboard-Layout für Echtzeit-Daten:
KPI-Karten (oben): 3-6 Metriken als große Zahlen. Jede Karte ist an eine Supabase-Abfrage gebunden, die aggregierte Daten zurückgibt (COUNT, SUM, AVG). Mit Realtime aktualisieren sich die Zahlen sofort wenn neue Daten eingehen.
Aktivitätsfeed (rechts): Eine Liste der letzten N Ereignisse, sortiert nach created_at DESC. Mit Realtime werden neue Einträge oben eingefügt ohne Seiten-Reload.
Tabellen/Diagramme (mitte): Zeitreihen-Diagramme für Trends, Tabellen für detaillierte Datensätze. Realtime-Updates für Diagramme sind performance-intensiver, aktualisiere nicht die vollständige Diagrammdaten bei jedem Event, sondern nur den neuesten Datenpunkt.
Für deutsche B2B-SaaS: denke an Zugriffskontrolle auf Dashboard-Ebene. Verschiedene Nutzerrollen sollen verschiedene KPIs sehen, implementiere das mit WeWebs Conditional Visibility basierend auf dem Nutzer-Rollen-Attribut aus Supabase Auth.
Performance-Optimierung für skalierte Dashboards
Echtzeit-Dashboards können die Performance degradieren, wenn nicht richtig implementiert:
Event-Throttling: Wenn Events sehr häufig kommen (jede Sekunde), aktualisiere nicht die UI bei jedem einzelnen Event. Sammle Events für 500ms und aktualisiere dann einmal. Implementiert in WeWeb mit einem Debounce-Timer.
Selektive Subscriptions: Abonniere nur die Tabellen und Spalten, die du wirklich brauchst. Supabase Realtime unterstützt filter-basierte Subscriptions: eq (gleich), lt (kleiner als), gt (größer als). Nutze das, um nur für deinen Workspace relevante Events zu empfangen.
Connection-Management: Jede geöffnete Browser-Tab erstellt eine neue WebSocket-Verbindung. Bei 1.000 gleichzeitigen Nutzern sind das 1.000 offene Verbindungen. Supabase Realtime skaliert das gut, aber füge immer Reconnect-Logik für unterbrochene Verbindungen hinzu.
Caching für aggregierte Daten: Berechne KPI-Metriken nicht bei jedem Realtime-Event neu. Nutze Materialised Views in Supabase oder cached Aggregate-Abfragen, die sich alle 30 Sekunden aktualisieren.
Praxisbeispiel: Bestellungs-Dashboard für Mittelstand
Ein konkreter Anwendungsfall: ein Mittelstandsunternehmen in Deutschland (Produktion, Handel) möchte ein Live-Dashboard, das neue Bestellungen, den Produktionsstatus und Lagerbestände zeigt.
Datenmodell: orders (id, customer, status, value, created_at), production_jobs (id, order_id, status, updated_at), inventory (id, product_id, quantity, updated_at).
Realtime-Setup: Abonniere orders für INSERT (neue Bestellungen), production_jobs für UPDATE (Statusänderungen), inventory für UPDATE (Lagerbestandsänderungen).
Dashboard: KPI-Karten für "Bestellungen heute", "Offene Aufträge", "Lager-Warnungen". Aktivitätsfeed für die letzten 20 Ereignisse. Tabelle für offene Bestellungen mit Echtzeit-Status-Updates.
Ergebnis: Produktionsleiter sehen sofort, wenn eine neue Bestellung eingeht oder ein Auftragsstatus sich ändert, ohne F5 zu drücken. Das wurde bisher mit Excel-Tabellen und E-Mail-Benachrichtigungen gelöst. WeWeb + Supabase Realtime ersetzt das in 4-6 Wochen.
DSGVO-Überlegungen für Echtzeit-Dashboards
Echtzeit-Dashboards, die personenbezogene Daten anzeigen, haben spezifische DSGVO-Anforderungen:
Zugriffsbeschränkung: Nur berechtigte Nutzer sollen bestimmte Daten in Echtzeit sehen. Implementiere das mit Supabase RLS auf Realtime-Subscriptions, Nutzer empfangen nur Events für ihre autorisierten Zeilen.
Keine unnötige Datenspeicherung im Browser: Echtzeit-Daten, die nur zur Anzeige benötigt werden, sollten nicht dauerhaft im LocalStorage des Browsers gespeichert werden. WeWeb-Variablen sind session-basiert, das ist standardmäßig richtig.
Audit-Log: Für sensible Business-Daten (Finanz, HR) implementiere einen Audit-Log in Supabase, der aufzeichnet wer wann was gesehen hat. Das ist eine Best-Practice für DSGVO-Artikel-5 (Rechenschaftspflicht) und wird von deutschen Unternehmens-DPOs bei Lieferantenaudits geprüft.
Supabase EU-Region: Realtime-WebSocket-Verbindungen laufen über die Supabase-Region. Wenn du EU-Region wählst, bleiben alle Daten, auch temporäre Realtime-Events, innerhalb der EU.
Zeitraum-Filterung
Jedes Dashboard braucht Zeitraum-Steuerungen. Muster: Füge eine Filter-Leiste mit voreingestellten Buttons hinzu: Letzte 24h, Letzte 7 Tage, Letzte 30 Tage, Benutzerdefinierter Zeitraum. Erstelle eine Seitenvariable dateRange mit Start- und End-Zeitstempeln. Übergib dateRange als Filter an jede Supabase-Collection: .gte("created_at", dateRange.start).lte("created_at", dateRange.end). Wenn der Nutzer einen anderen Zeitraum wählt, aktualisiere dateRange, alle Collections laden automatisch neu.
Für benutzerdefinierte Datumsbereiche nutze WeWebs Date-Picker-Komponente und binde beide Eingaben an dateRange.start und dateRange.end.
Dashboard-Datenaktualisierungsstrategien
Nicht jeder Teil der Dashboard-Daten profitiert von Realtime-Subscriptions. Manche Daten ändern sich selten (Kontoeinstellungen, Nutzerprofil), manche nach einem festen Zeitplan (Tagessummen, Wochenberichte), und manche kontinuierlich (Live-Ereignisse, aktive Sessions). Die Aktualisierungsstrategie an den Datentyp anzupassen ergibt ein leistungsfähigeres Dashboard.
Für kontinuierlich wechselnde Daten (Bestellzahlen, aktive Nutzer, Live-Umsatz) sind Supabase-Realtime-Subscriptions die richtige Wahl. Daten aktualisieren sich in unter 500ms vom Datenbank-Insert bis zum Dashboard-Update. Für Daten, die sich nach einem Zeitplan ändern (gestrige Summen, letzte Wochenzusammenfassung), reicht eine manuelle Aktualisierung oder ein zeitgesteuertes Neuladen alle 60 Sekunden, keine Realtime-Subscription nötig.
Implementiere in WeWeb das zeitgesteuerte Neuladen mit einem setInterval in einer JavaScript-Aktion beim Seitenladen, die ww.collections.refresh('deine-collection-name') im konfigurierten Intervall aufruft. Für ein hybrides Dashboard mit sowohl Live- als auch geplanten Daten: Realtime kümmert sich um die Live-Feeds, während zeitgesteuerte Aktualisierungen die Zusammenfassungskarten korrekt halten. Diese Kombination ist effizienter, als alles an Realtime zu abonnieren, sie reduziert das WebSocket-Event-Volumen und vermeidet unnötige Re-Renders stabiler Daten.
Realtime-Verbindungsfehler elegant behandeln
WebSocket-Verbindungen brechen ab. Mobile Nutzer wechseln Netzwerke. Unternehmens-Firewalls blockieren WebSocket-Upgrades. Ein produktives Realtime-Dashboard muss Verbindungsabbrüche elegant behandeln, statt stillschweigend veraltete Daten zu zeigen.
Supabases Realtime-JavaScript-Client hat eingebaute Reconnect-Logik. Wenn das WebSocket die Verbindung trennt, versucht der Client automatisch mit exponentiellem Backoff, sich wieder zu verbinden. Während der Trennung werden Datenbankänderungen jedoch nicht vom Client empfangen. Wenn die Wiederverbindung erfolgreich ist, solltest du die betroffenen Collections neu laden, um verpasste Änderungen nachzuholen, einen Gap Fetch.
Implementiere in WeWeb den Gap Fetch, indem du die onError- und onClose-Events des Supabase-Kanals mit einer benutzerdefinierten JavaScript-Aktion abonnierst. Wenn eines der Events feuert, setze eine Seitenvariable connectionStatus auf 'reconnecting' und zeige einen sichtbaren Statusindikator im Dashboard. Wenn sich der Kanal wieder verbindet (onJoin-Event), aktualisiere alle Realtime-Collections und setze connectionStatus zurück auf 'connected'. Dieses Muster stellt sicher, dass Nutzer immer wissen, ob die angezeigten Daten live und aktuell sind.
Fallstudie: Finanz-Dashboard
Eine der anspruchsvollsten Realtime-Dashboard-Implementierungen, die wir bei App Studio gebaut haben, ist ein Finanzoperations-Dashboard für ein Fintech-Startup, das Zahlungen über mehrere europäische Märkte hinweg verarbeitet. Das Dashboard verfolgt Live-Transaktionsvolumen, Genehmigungsraten nach Zahlungsmethode, Betrugsmarkierungen und Abwicklungsstatus, alles in Echtzeit aktualisiert, während Transaktionen verarbeitet werden.
Die Architektur nutzt Supabase als zentrales Data Warehouse. Eine Edge Function empfängt Webhook-Payloads vom Zahlungsdienstleister und fügt verarbeitete Transaktionsdatensätze in die transactions-Tabelle ein. Die Realtime-Subscription in WeWeb feuert bei jedem Insert, und das Dashboard aktualisiert die Live-Zähler, fügt die neue Transaktion zur Datentabelle hinzu und berechnet das Genehmigungsraten-Diagramm neu, alles innerhalb von 600ms nach der Zahlungsverarbeitung.
Wichtige Implementierungsdetails, die das im großen Maßstab funktionieren ließen: Materialized Views für stündliche Aggregate (um teure COUNT/SUM-Operationen auf der vollständigen Transaktionstabelle zu vermeiden), ein zusammengesetzter Index auf (org_id, created_at, status) für das häufige Abfragemuster, und UI-Update-Batching, um Bursts von 20 bis 30 Transaktionen pro Sekunde während Spitzenzeiten zu bewältigen. Das Dashboard verarbeitet 50.000+ tägliche Transaktionen ohne Performance-Einbußen, betrieben auf Supabases Pro-Plan. Das ist dieselbe Architektur, die wir auf jedes datenintensive WeWeb-Dashboard anwenden, das wir bauen.