Saltar al contenido
Volver al blog
LaravelHomelabSelf-hosting

Mercure Broadcasting en Laravel 13.32

Laravel incorpora Mercure para emitir eventos en tiempo real con SSE y un hub que puedes alojar por tu cuenta.

Ismael Catala4 min de lectura

Menos dependencia de un servicio externo

Cuando una aplicación necesita actualizar la interfaz en tiempo real, la salida habitual suele ser Pusher o un servidor WebSocket propio. Laravel 13.32 suma Mercure como driver de broadcasting y abre otra vía: publicar eventos mediante Server-Sent Events. Me parece interesante sobre todo si quiero mantener el hub dentro de mi infraestructura, por ejemplo en un homelab o en un servidor que ya administro. (laravel-news.com)

Un hub separado, pero bajo mi control

Mercure funciona alrededor de un hub al que Laravel publica actualizaciones y al que el navegador se suscribe. Laravel diferencia la URL interna de publicación de la URL pública que consumirá el cliente, algo útil si la aplicación y el hub no comparten la misma red o el mismo nombre DNS. El secreto JWT de Laravel debe coincidir con el configurado en el hub. (laravel.com)

La configuración mínima

La conexión se activa con BROADCAST_CONNECTION=mercure. MERCURE_URL apunta al endpoint que Laravel usa para publicar, mientras que MERCURE_PUBLIC_URL es la dirección que utilizará el navegador. No pondría estos valores directamente en código ni reutilizaría un secreto compartido con otros servicios sin revisar antes cómo está aislado el hub.

BROADCAST_CONNECTION=mercure
 
MERCURE_URL=https://mercure.example.com/.well-known/mercure
MERCURE_PUBLIC_URL=https://mercure.example.com/.well-known/mercure
MERCURE_JWT_SECRET=<your-mercure-jwt-secret>
 
VITE_MERCURE_HUB_URL="${MERCURE_PUBLIC_URL}"

La documentación oficial indica que el hub debe usar el mismo secreto JWT. También deja clara la separación entre la URL usada por PHP y la que se expone al navegador, que es un detalle fácil de romper detrás de un proxy inverso. (laravel.com)

Echo también entiende Mercure

En el frontend no hace falta montar un cliente distinto para escuchar los eventos: Laravel Echo incluye un broadcaster llamado mercure. Basta instalar laravel-echo y crear la instancia indicando ese broadcaster y el host del hub. Si no se especifica, Echo asume /.well-known/mercure en el origen actual. (laravel.com)

Esto mantiene bastante estable la parte de aplicación. Los eventos siguen implementando ShouldBroadcast, y los canales públicos o privados siguen siendo conceptos de Laravel, no una API nueva que haya que aprender desde cero. Para el código de dominio, cambiar el transporte no debería obligar a rediseñar cada evento. (laravel.com)

Privados, presencia y cifrado

Los canales privados conservan la autorización definida en routes/channels.php, de modo que no basta con conocer el nombre de un canal para suscribirse. Los canales de presencia también siguen el modelo habitual: la autorización puede devolver información del usuario y Echo ofrece here, joining y leaving para reflejar quién está conectado. Esto permite cubrir casos como una sala de soporte, una edición compartida o un panel de operadores sin abandonar el modelo de broadcasting de Laravel. (laravel.com)

Para los canales privados cifrados de extremo a extremo, Laravel documenta MERCURE_ENCRYPTION_KEY. Debe ser una clave de 32 bytes, así que no conviene improvisarla con una contraseña corta o copiar una variable sin comprobar su formato. El cifrado es una capa adicional; no sustituye la autorización correcta del canal ni la protección del hub. (laravel.com)

La letra pequeña

Mercure no elimina la necesidad de operar un componente más: hay que desplegar, actualizar y vigilar el hub, además de proteger sus secretos y sus URLs públicas. Tampoco convierte SSE en un canal bidireccional; si el navegador necesita enviar acciones al servidor, seguirá haciéndolo por HTTP u otro mecanismo que decida la aplicación. Elegir Mercure tiene sentido cuando la entrega desde servidor hacia cliente es el problema principal, no como sustituto automático de cualquier caso de uso con WebSockets.

También conviene recordar que Laravel procesa normalmente los broadcasts mediante trabajos en cola. Hay que tener un worker funcionando y pensar qué sucede si se emite un evento dentro de una transacción que todavía no se ha confirmado. Mercure simplifica el transporte, pero no resuelve por sí solo la consistencia de datos ni el diseño de eventos. (laravel.com)


Fuente: Laravel News (laravel-news.com) Documentación oficial de Laravel Broadcasting (laravel.com)