Eventos Enviados por el Servidor (SSE): Obteniendo Actualizaciones en Tiempo Real en tus Apps
Si alguna vez has construido un panel de control (dashboard) o una pantalla de operaciones, conoces el problema. Quieres que los números en pantalla reflejen lo que realmente está sucediendo en el servidor, pero tampoco quieres escribir un bucle de sondeo (polling) que dispare una solicitud cada segundo y sature tu backend, haya cambiado algo o no. Tiene que haber una manera mejor.
Para una gran clase de escenarios con muchas actualizaciones, esa mejor manera son los Eventos Enviados por el Servidor (SSE): una forma estándar basada en HTTP para que un servidor mantenga una conexión abierta y transmita actualizaciones al cliente a medida que ocurren. Recientemente, RAD Studio 13.1 agregó soporte de primera clase para esto, tanto en el lado del servidor como en el del cliente, por lo que construimos una pequeña prueba de concepto para mostrar cómo se ve esto de principio a fin.
Índice de Contenidos
- ¿Qué significa SSE?
- SSE en RAD Studio: Los Fundamentos
- El Lado del Servidor (WebBroker)
- El Lado del Cliente (THTTPEventSource)
- La demostración de Eventos Enviados por el Servidor (SSE)
- ¿Cómo encaja nuestra demostración de SSE en el servidor?
- Los Eventos Enviados por el Servidor no son una tecnología exclusiva de Delphi
- ¿Cómo encaja MCP con SSE?
- ¿Qué sigue?
¿Qué significa SSE?
La idea detrás de SSE es sencilla. El cliente abre una conexión HTTP normal al servidor y la mantiene abierta. En lugar de que el servidor envíe una respuesta y cierre la conexión como una página web normal, retiene la conexión y empuja datos al navegador o aplicación del usuario cada vez que sucede algo digno de informar. El cliente procesa cada fragmento a medida que llega y actualiza la interfaz de usuario en consecuencia.
Donde SSE brilla es precisamente en este tipo de escenarios: el servidor sabe cosas que el cliente necesita ver, y el trabajo del cliente es principalmente mostrarlas. Métricas en vivo, datos de gráficos, progreso de trabajos, notificaciones, seguimiento de registros... Para cualquiera de estos, SSE es un ajuste natural y considerablemente más simple de implementar que una configuración completa de WebSocket.
Los WebSockets son realmente útiles cuando necesitas comunicación bidireccional de alta frecuencia en el mismo canal que el contenido inicial, o cuando estás construyendo algo con un protocolo bidireccional complejo. Pero para las actualizaciones de servidor a cliente, SSE suele ser la opción más limpia y óptima:
- Funciona sobre HTTP simple, sin requerir un protocolo especial.
- Reconexión incorporada en cada navegador, y en RAD Studio utilizando THTTPEventSource.
- Los tipos de eventos con nombre mantienen la lógica del lado del cliente simple y explícita.
SSE en RAD Studio: Los Fundamentos
Veamos el código requerido para hacer que SSE funcione en RAD Studio 13.1. Gracias a la nueva unidad System.Net.HttpSse y las actualizaciones de WebBroker, la implementación interna es notablemente sencilla.
Para convertir una respuesta HTTP estándar en una conexión SSE de transmisión continua, debes actualizar la respuesta utilizando TWebResponseStream.BeginEventsStream. A partir de ahí, simplemente escribes tus eventos en un bucle mientras el cliente permanezca conectado.
El Lado del Cliente (THTTPEventSource)
En el lado del cliente, utilizas el nuevo THTTPEventSource. Este maneja la conexión HTTP en segundo plano y pone en cola los eventos entrantes. Tu trabajo es simplemente sacarlos de la cola y leer los datos.
Ahora que ves la mecánica subyacente, veamos cómo tomamos esta base y la escalamos a un sistema más avanzado con tiempos personalizados, hilos en segundo plano y múltiples canales de eventos.
La demostración de Eventos Enviados por el Servidor (SSE)
La demostración que construimos en torno a esto tiene tres piezas: un servidor de consola WebBroker en Delphi, una página de panel de navegador servida desde ese mismo servidor usando WebStencils, y una aplicación de escritorio nativa FireMonkey (FMX). Los tres se ejecutan al mismo tiempo, y tanto el navegador como los clientes FMX se conectan al mismo endpoint de SSE.
El servidor expone un endpoint /events. Cuando un cliente se conecta, el servidor mantiene esa conexión abierta y comienza a enviar eventos con nombre en un bucle. Tres tipos de eventos fluyen a través de la transmisión:
- heartbeat — se dispara en un intervalo configurable para mantener la transmisión viva y confirmar que el servidor sigue ahí.
- dashboard — transporta instantáneas en vivo de los KPI: usuarios activos, total de ventas y valor promedio de los pedidos.
- progress — aparece cuando se está ejecutando un trabajo en segundo plano, actualizándose a medida que el trabajo avanza.
Lo que lo hace concreto es el disparador del trabajo. Presiona el botón "Start Job" desde cualquier cliente y ambas interfaces de usuario comenzarán a recibir actualizaciones de progreso simultáneamente. La barra de progreso del navegador y la de FMX se mueven a la par porque ambas están leyendo del mismo estado en el lado del servidor.
HAZ CLIC AQUÍ PARA DESCARGAR LA DEMO
¿Cómo encaja nuestra demostración de SSE en el servidor?
El lado del servidor está construido usando WebBroker. El endpoint SSE utiliza TWebResponseStream.BeginEventsStream para abrir la respuesta de transmisión y luego se queda en un bucle mientras la conexión está viva, emitiendo eventos a medida que sus temporizadores de cadencia se activan. Cada cliente puede ajustar su propia frecuencia de actualización con parámetros de consulta, por lo que un cliente puede solicitar heartbeats (latidos) cada segundo mientras que otro los pide cada cinco segundos. El servidor restringe los valores a un rango sensato y maneja el resto.
Esa es la esencia: abrir la transmisión SSE, escribir un evento con nombre con carga útil JSON (o cualquier otro dato) y finalizar el bloque.
El estado del panel y del trabajo se comparten entre todas las conexiones a través de un par de objetos singleton seguros para hilos (thread-safe). Eso es lo que mantiene la consistencia de los números: cada cliente que solicita una instantánea del panel obtiene los mismos valores subyacentes, no un comportamiento aleatorio por conexión que pierda la sincronía.
En el lado del cliente, el navegador utiliza la API EventSource integrada. La aplicación FMX utiliza THTTPEventSource de System.Net.HttpSse, que se agregó en RAD Studio 13.1. Ambos clientes escuchan los mismos nombres de eventos y actualizan sus elementos de interfaz cuando esos eventos llegan. El servidor no sabe ni le importa si un cliente es un navegador o una aplicación Delphi. El formato del evento es el mismo en ambos casos.
Los Eventos Enviados por el Servidor no son una tecnología exclusiva de Delphi
Vale la pena ser claros sobre algo: SSE es un estándar web abierto. RAD Studio te brinda una forma nativa de crearlos y usarlos, pero el formato subyacente de cómo funcionan los eventos del lado del servidor es entendido por todas las pilas HTTP y los principales navegadores. Eso significa que un servidor Delphi puede enviar eventos a un cliente JavaScript, un cliente Python, un cliente Go o cualquier otra cosa que "hable" HTTP. Igualmente, una aplicación Delphi que utiliza THTTPEventSource puede consumir flujos SSE de servicios que no sean de Delphi sin ninguna adaptación especial.
Este último punto es muy útil en la práctica hoy en día. Varias de las principales API de producción públicas ya transmiten sus respuestas a través de SSE:
- API de Respuestas de OpenAI — transmite la salida del modelo token por token.
- API de Mensajes de Anthropic — transmite respuestas de Claude con stream: true.
- Transporte HTTP Transmisible de MCP — utiliza SSE para el tramo de transmisión de la comunicación de servidor a cliente.
Una aplicación Delphi con THTTPEventSource puede conectarse directamente a cualquiera de esas API, sin tener que escribir un analizador de transmisión HTTP personalizado para procesar los resultados de SSE.
¿Cómo encaja MCP con SSE?
Hay un tema relacionado que vale la pena mencionar. El Protocolo de Contexto de Modelos (MCP) se ha convertido en un estándar común para conectar herramientas, editores y agentes de IA a capacidades externas. El transporte HTTP original de MCP se construyó sobre SSE, y aunque la especificación actual se ha movido hacia un transporte más flexible llamado HTTP Transmisible (Streamable HTTP), ese transporte más nuevo todavía utiliza SSE para el tramo de transmisión de su comunicación. En términos prácticos, muchas implementaciones de MCP en el mundo real en uso hoy en día todavía se basan en SSE, e incluso las más nuevas dependen de los mismos fundamentos de transmisión.
La relevancia aquí es que si estás pensando en construir integraciones de MCP en Delphi, o conectarte a servidores MCP de terceros que otros están desarrollando, el conocimiento de transmisión de esta demostración se transfiere directamente. No necesitarías construir tu propia capa de transmisión HTTP desde cero. Los mismos mecanismos de THTTPEventSource que demuestra esta PoC (prueba de concepto) son los que utilizarías.
¿Qué sigue?
Esta demostración es intencionalmente pequeña. Los KPI del panel se simulan aleatoriamente y el trabajo en segundo plano es un temporizador. El punto no son los datos, es la implementación interna. Como mostramos en esta demostración, una vez que comprendes cómo fluyen los eventos enviados por el servidor desde un endpoint de WebBroker de Delphi a una página de navegador y una aplicación FMX simultáneamente, reemplazar los datos simulados con eventos comerciales reales de tus propios servicios es un paso sencillo.
Si has estado buscando una forma práctica de agregar actualizaciones en tiempo real a una aplicación de RAD Studio sin asumir una complejidad arquitectónica significativa, este es un excelente lugar para comenzar.
.png)
Comentarios
Publicar un comentario