Bestellung bestätigt, Fahrer noch zwei Stopps entfernt, Preisalarm ausgelöst: Ihr Backend publiziert das Ereignis einmal, und jeder abonnierte Browser-Tab und jede Mobile-App erhält es sofort per MQTT über sichere WebSockets — ohne Polling und ohne eigenen Socket-Server.
Keine Kreditkarte erforderlich
PUBLISH orders/ord-58213/status
{"status":"out_for_delivery","eta":"14:35","stops_away":2,"courier":"c-221","ts":"2026-10-22T14:02:51Z"}QoS 1 · TLS 8883 · PUBACK
Apps, die alle paar Sekunden eine API abfragen, belasten Ihr Backend und wirken trotzdem träge. Ein eigener WebSocket-Dienst heißt: Reconnect-Logik, Fan-out und horizontale Skalierung selbst bauen — und wer vom WLAN ins Mobilfunknetz wechselt, verpasst trotzdem genau das wichtige Update.
Bestellservice, Dispositionssystem oder Alarm-Job publizieren bei jeder Änderung ein kleines JSON-Ereignis auf ein Topic wie orders/{Bestell-ID}/status.
Web-Apps verbinden sich mit MQTT.js über sichere WebSockets, Mobile-Apps mit einem nativen MQTT-Client, und abonnieren die Topics des jeweiligen Nutzers.
ConnectMQ stellt jedes Ereignis allen abonnierten Clients gleichzeitig zu — dem Smartphone des Kunden, seinem offenen Browser-Tab und der Konsole Ihres Support-Teams.
Die App rückt die Sendungsverfolgung weiter, aktualisiert ein Badge oder zeigt ein In-App-Banner. Für geschlossene Apps sendet Ihr eigener Push-Dienst weiter über APNs und FCM.
MQTT über sichere WebSockets lässt Browser direkt mit demselben Broker sprechen, den Ihr Backend per MQTT mit TLS erreicht.
Authentifizierung per Benutzername und Passwort und Topic-ACLs beschränken jeden Client auf seinen Teilbaum wie users/{id}/#; publizieren darf dort nur Ihr Backend.
Retained Messages liefern den letzten Bestellstatus, sobald die App abonniert; persistente Sessions mit QoS 1 stellen zu, was während einer kurzen Unterbrechung verpasst wurde.
QoS 0 für häufige Fahrerpositionen, bei denen nur die neueste zählt, QoS 1 für Statusänderungen und Alarme, die ankommen müssen.
orders/ord-58213/status (retained)
orders/ord-58213/courier/location
users/u-90417/notifications
users/u-90417/badge (retained)Beides — MQTT läuft über WebSockets. Ein reiner WebSocket ist nur eine Leitung: Topics, Fan-out, Reconnects und Zustellgarantien müssen Sie selbst bauen. MQTT über sichere WebSockets bringt Publish/Subscribe, QoS, Retained Messages und Last Will mit, und ConnectMQ betreibt die Serverseite.
Für geöffnete oder im Vordergrund laufende Apps ja: MQTT liefert Updates schneller und mit mehr Daten. Bei geschlossener App begrenzen iOS und Android Hintergrundverbindungen, dafür bleiben APNs und FCM. Bewährt hat sich: einmal publizieren und ausgewählte Ereignisse von einem kleinen Dienst als Push weiterleiten lassen.
Mit MQTT.js: Verbinden Sie sich mit dem Secure-WebSocket-Endpunkt von ConnectMQ, abonnieren Sie die Topics des Nutzers und aktualisieren Sie den State bei jeder Nachricht. Liefern Sie nie Zugangsdaten mit weitreichenden Rechten im Frontend aus — Browser-Clients erhalten Zugangsdaten, deren ACL nur das Lesen eigener Topics erlaubt.
Starten Sie im Free-Plan – ohne Kreditkarte – verbinden Sie heute Ihre ersten Geräte und upgraden Sie, wenn Sie live gehen.
