Pregunta Cómo mezclar spring-data-rest con springsocket en una sola implementación


Me gustaría sincronizar el estado con todos los clientes interesados ​​en cambios de entidades particulares. Entonces me gustaría lograr algo como:

  • exponiendo la API CRUD en la entidad (a través de HTTP/REST y websockets)
  • y enrutar la respuesta (de las llamadas modificadoras) a websockets tema

Entonces, técnicamente, estaría interesado en ideas para mezclar spring-data-rest con implementación de websockets de primavera para lograr algo como spring-data-websocket.

Me vienen a la mente dos soluciones y, de hecho, ambas serían:

  • spring-data-rest para exponer mis entidades a través de REST/HTTP API
  • websocket Controladores (usados ​​para las llamadas de modificación a las entidades)

los websocket los controladores se verían así:

@Controller
public class EntityAWebSocketController {
      @MessageMapping("/EntityA/update")
      @SendTo("/topic/EntityA/update")
      public EntityA update(EntityA entityA) throws Exception {
           // persist,....
           return entityA;
     }
}

Escenario 1: Websocket API llamado desde REST/HTTP API

Reglas:

  • la solicitud del cliente es siempre REST/HTTP API
  • la respuesta es REST/HTTP API para todas las operaciones
  • además para modificar las operaciones websocket el mensaje también viene

Técnicamente, podría lograrse, por:

  • llamando al websocket controladores de la eventos spring-rest-data (a saber, en AfterCreateEvent, AfterSaveEvent, AfterLinkSaveEvent, AfterDeleteEvent)

Todavía la solución me parece bastante enfermiza, como debería ir por:

  1. cliente A -HTTP solicitud -> Servidor (controlador spring-data-rest)
  2. Servidor (AfterXXXEvent en el controlador spring-data-rest) -websocket mensaje -> Primavera websocket controlador
  3. Controlador websocket de muelle -websocket mensaje por tema -> todos los clientes interesados ​​en el tema
  4. Servidor (controlador Spring-data-rest) -HTTP respuesta -> cliente A

Escenario 2: Websocket API independiente de REST API

Reglas:

  • la solicitud del cliente es REST/HTTP API solo para operaciones que no modifican
  • la respuesta es REST/HTTP API solo para operaciones que no modifican
  • el cliente envía websocket mensaje para todas las operaciones de modificación
  • websocket el mensaje se envía al cliente solo para todas las operaciones de modificación

Bueno, si no surgen otras ideas, iría por la última, pero aún así, sería genial si pudiera haber generado de alguna manera C(R)UD métodos expuestos a través de websockets también, algo así como spring-data-websockets y manejar solo las rutas en mi implementación.

Como siento que tendría que exponer manualmente (a través de *WebSocketControllers) todo el CUD métodos para todas mis entidades. Y podría ser demasiado flojo para eso.

Ideas?


32
2018-01-22 08:58


origen


Respuestas:


El escenario 2 se refiere, en el último paso, a un solo cliente. Pero pensé que su requisito era un tema, ya que quería varios clientes. Si quería completar 2 para su requerimiento establecido, entonces puede mantener una lista de clientes e implementar su propia cola o utilizar ForkJoinPool para enviar mensajes a todos sus clientes que escuchan en sus WebSockets. Una vez dicho esto, un tema es definitivamente más elegante aquí, pero en general parece demasiado complicado con diferentes interfaces

Para todos los mensajes de cliente a servidor, simplemente vaya con un protocolo simple y use una colección para parametrizar, podría ser RParam1 .......

En el servidor, necesita un controlador para asignarlos a diferentes solicitudes (y operaciones). De alguna manera, no parece demasiado trabajo. Espero que esto ayude.


1
2018-06-21 17:33