Al usar Server-Sent Events ¿debería el cliente establecer conexiones múltiples para recibir diferentes eventos en los que está interesado, o debería haber una conexión única y el cliente indica lo que está interesado a través de un canal separado? IMO este último parece más preferible, aunque para algunos podría hacer que el código del cliente sea más complejo. La especificación admite eventos con nombre (eventos que se relacionan con un tema en particular), lo que para mí sugiere que una conexión de eventos enviados por el servidor se debe usar como un solo canal para todos los eventos.¿Debería haber solo un objeto EventSource por aplicación?
El siguiente código ilustra el primer escenario en el que se inician a las conexiones múltiples eventos enviados por el servidor:
var EventSource eventSource1 = new EventSource("events/topic1");
eventSource1.addEventListener('topic1', topic1Listener, false);
var EventSource eventSource2 = new EventSource("events/topic2");
eventSource2.addEventListener('topic2', topic2Listener, false);
eventSource1 recibiría eventos "tema1" y eventSource2 recibiría eventos "Tema2". Si bien esto es bastante simple también es bastante ineficiente con un colgante GET se producen para cada tema que le interesa en
La alternativa es algo como lo siguiente:.
var EventSource eventSource3 = new EventSource("/events?id=1234")
eventSource3.addEventListener('topic3', topic3Listener, false);
eventSource3.addEventListener('topic4', topic4Listener, false);
var subscription = new XMLHttpRequest();
subscription.open("PUT", "/events/topic3?id=1234", true);
subscription.send();
En este ejemplo, una sola EventSource haría existen y el interés en un evento en particular se especificaría mediante una solicitud por separado con la conexión de Evento enviado por el servidor y el registro correlacionado por el id param. topic3Listener recibiría eventos "topic3" y topic4Listener no lo haría. Aunque se requiere un poco más de código, la ventaja es que solo se realiza una conexión única, pero los eventos aún pueden identificarse y manejarse de manera diferente.
Hay un número ejemplos en la web que muestran el uso de eventos con nombre, pero parece que los nombres de eventos (o temas) son conocidos de antemano por lo que no es necesario que un cliente registre interés con el servidor (example) Aunque todavía no he visto un ejemplo que muestre varios objetos de EventSource, tampoco he visto un ejemplo que muestre a un cliente usando una solicitud por separado para registrar el interés en un tema en particular, como lo estoy haciendo arriba. Mi interpretación de la especificación me lleva a creer que indicar un interés en un tema determinado (o nombre de evento) depende completamente del desarrollador y que se puede hacer de forma estática con el cliente sabiendo los nombres de los eventos que va a recibir o dinámicamente con el cliente alertando al servidor que está interesado en recibir eventos particulares.
Estaría muy interesado en escuchar las opiniones de otras personas sobre el tema. NB: Por lo general, soy un desarrollador de Java así que perdona mi mediocre código JS ... :)
no se puede utilizar en todos los nombres de eventos en el caso de la corriente, en lugar usted puede escuchar para el evento "mensaje" y en el event.data puede codificar el topicId e información adicional – 4esn0k
Sí, claro, pero eso significaría que necesito codificar esos datos en la carga útil, lo que realmente no tiene sentido cuando la identificación del mensaje ya es parte del encuadre de datos de la especificación. –
+1! muy buena pregunta. Lo acabaste haciendo ? También estoy pensando en ir con el segundo enfoque. Le agradecería si comparte si tuvo algún problema con él. – brainOverflow