Realtime-Kommunikation

Wenn eine Anwendung nicht auf den nächsten Refresh warten soll

Ich entwerfe Ereigniskommunikation, wenn Nutzer oder Systeme Informationen sofort erhalten sollen.

Polling ist nicht immer die Antwort

Aktueller Zustand ohne wiederholte Serveranfragen

Beim Polling fragt der Browser wiederholt nach Änderungen. Ein Realtime-Modell liefert ein Ereignis erst, wenn es entsteht.

Was Realtime lösen kann

Die Auswahl hängt von Ereignistyp, Berechtigungen und gewünschter Zuverlässigkeit ab.

WebSocket-Kommunikation

Bidirektionale Verbindung zwischen Browser und Realtime-Schicht.

Publish / subscribe

Ereignisse werden nur an relevante Topics und Abonnenten zugestellt.

Monitoring und Verarbeitung

Für Dashboards, Benachrichtigungen, CRM, Reservierungen und Hintergrundprozesse.

Typische Szenarien

Live-Dashboards und Monitoring
Status von Aufträgen, Reservierungen oder CRM
Browser-Benachrichtigungen
KI- und Worker-Prozesse, die Ergebnisse veröffentlichen

Technische Sicht

Ein eigener WebSocket-Broker kann eine Umsetzung sein. Entscheidend sind Topic-Routing, Namespaces, Autorisierung und Beobachtbarkeit.

PHP backend
     ↓ REST publish
Realtime broker
   ├── Browser
   ├── Worker
   └── AI service

Zusammenarbeit

Ereignis, Ablauf und Zugriffskontrolle

Ereignisse Was soll an wen zugestellt werden.
Kanäle Topics, Namespaces und Zugriffsregeln.
Betrieb Monitoring, Fehlerzustände und Verhaltensprüfung.

Entscheidung nach Einsatz

WebSocket wird nicht für alles benötigt

Polling fragt regelmäßig nach einem neuen Zustand und kann bei seltenen Änderungen völlig ausreichen. Eine dauerhafte WebSocket-Verbindung hilft bei niedriger Latenz oder vielen Clients, braucht aber Reconnect, Heartbeats, Autorisierung und Monitoring.

Relevante Technologien

Go WebSocket REST Wildcard topics Namespaces Authorization Monitoring Docker

Beispielszenario

Sofortige Ereigniszustellung ohne regelmäßiges Polling

Das Backend veröffentlicht eine Änderung; Browser oder Worker erhalten nur das relevante Ereignis.

Backend
  ↓ publish
Broker
  ↓ event
Browser

Soll die Anwendung sofort reagieren?

Beschreiben Sie Ereignis, Nutzer und erwartetes Verhalten.

Realtime-Lösung besprechen →

Menü