Pedido confirmado, repartidor a dos paradas, alerta de precio activada: tu backend publica el evento una vez y cada pestaña del navegador y cada app móvil suscrita lo recibe al instante por MQTT sobre WebSockets seguros, sin polling ni servidor de sockets propio.
Sin tarjeta
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
Las apps que consultan una API cada pocos segundos cargan tu backend y aun así se sienten lentas. Un servicio WebSocket propio implica programar reconexiones, fan-out y escalado horizontal, y un usuario que pasa del Wi-Fi a los datos móviles sigue perdiéndose justo la actualización que importaba.
El servicio de pedidos, el sistema de reparto o el job de alertas publica un pequeño evento JSON en un topic como orders/{id de pedido}/status cada vez que algo cambia.
Las apps web se conectan con MQTT.js por WebSockets seguros, las móviles con un cliente MQTT nativo, y se suscriben a los topics de ese usuario.
ConnectMQ entrega cada evento a todos los clientes suscritos a la vez: el móvil del cliente, su pestaña abierta y la consola de tu agente de soporte.
La app avanza el seguimiento del pedido, actualiza un contador o muestra un banner. Para apps cerradas, tu propio servicio de push sigue enviando por APNs y FCM.
MQTT sobre WebSockets seguros permite que el navegador se conecte directamente al mismo broker al que tu backend llega por MQTT con TLS.
La autenticación con usuario y contraseña y las ACL por topic limitan a cada cliente a su propio árbol, como users/{id}/#, y solo tu backend puede publicar en él.
Los mensajes retenidos entregan el último estado del pedido en cuanto la app se suscribe; las sesiones persistentes con QoS 1 entregan lo perdido durante un corte breve.
QoS 0 para la posición del repartidor, donde solo importa la última, y QoS 1 para cambios de estado y alertas que tienen que llegar.
orders/ord-58213/status (retained)
orders/ord-58213/courier/location
users/u-90417/notifications
users/u-90417/badge (retained)Ambos: MQTT funciona sobre WebSockets. Un WebSocket puro es solo un canal; aún tienes que construir topics, fan-out, reconexiones y garantías de entrega. MQTT sobre WebSockets seguros añade publicación/suscripción, QoS, mensajes retenidos y Last Will, y ConnectMQ se encarga del lado servidor.
Para apps abiertas o en primer plano, sí: MQTT entrega las actualizaciones más rápido y con más datos. Con la app cerrada, iOS y Android limitan las conexiones en segundo plano, así que mantén APNs y FCM para esos casos. Un patrón habitual es publicar una vez y que un pequeño servicio reenvíe ciertos eventos como push.
Usa MQTT.js: conéctate al endpoint de WebSockets seguros de ConnectMQ, suscríbete a los topics del usuario y actualiza el estado con cada mensaje. Nunca incluyas en el front-end una credencial con permisos amplios: da a los clientes del navegador credenciales cuya ACL solo permita leer sus propios topics.
Empieza con el plan Free, sin tarjeta: conecta hoy tus primeros dispositivos y mejora tu plan cuando entres en producción.
