0
702
VistasAmpliación de la API REST de Flask con WebSockets
Actualmente estoy trabajando para ampliar mi API REST existente creada con Flask-RESTPlus con compatibilidad con WebSocket. La idea es crear una Web Thing compatible con Web Thing Model (Gateway). Las "Cosas" en mi caso de uso se agregan o eliminan dinámicamente.
La configuración actual permite que un consumidor obtenga los valores más recientes de una Cosa, por ejemplo, un sensor de temperatura, mediante una solicitud HTTP GET a /thingId/properties/temperature . En realidad, los valores se consumen de Kafka y se almacenan temporalmente en Redis.
Ahora me pregunto cómo puedo extender esta configuración y permitir que el consumidor no solo sondee los valores más recientes, sino que se suscriba a la propiedad de una Cosa usando WebSockets. Tengo una solución funcional en la que creo "Habitaciones" para cada propiedad, pero esto requiere dos servidores separados y la duplicación de puntos finales.
Para DESCANSO tengo
@app.route('/<thingId>/properties/<propertyId>') # get latest datapoint return latestDatapointPara Flask-SocketIO tengo
@socketio.on('join') def on_join(data): username = data['username'] room = data['room'] # eg /thingId/properties/temperature join_room(room) send(username + ' has entered the room.', room=room)y luego reenvío los datos a la sala correcta tal como vienen de Kafka. En el lado del cliente, necesito conectarme al servidor WebSocket y unirme a la sala
socket.on('connection', function(socket){ socket.emit('join', 'some room'); }); Esta implementación funciona, pero tenía grandes esperanzas de un flujo de trabajo alternativo, como se muestra en la figura a continuación, donde el cliente se conecta al mismo punto final que se usa en la API REST, pero con el protocolo WebSocket en lugar de unirse a las salas, etc. 
¿Tiene alguna idea de si esto ya existe o es factible de implementar?
1 Respuestas
Responde la pregunta0
Tengo una solución funcional en la que creo "Habitaciones" para cada propiedad, pero esto requiere dos servidores separados y la duplicación de puntos finales.
El servidor Socket.IO y su servidor HTTP no necesariamente tienen que estar separados. En todas las configuraciones admitidas, puede alojar aplicaciones HTTP y Socket.IO con un solo servidor.
Tampoco veo la duplicación del punto final, pero tal vez esto se deba a que piensa en los controladores de eventos Socket.IO como puntos finales, cuando en realidad no lo son. Con Socket.IO hay un punto final único en el sentido de HTTP, ya que todo el tráfico de Socket.IO viaja en una sola URL. Sus controladores de eventos son solo eso, funciones que se invocan cuando ciertos eventos aparecen en el punto final de Socket.IO.
donde el cliente se conecta al mismo punto final utilizado en la API REST, pero con el protocolo WebSocket en lugar de unirse a salas, etc.
Entonces, ¿quiere que su cliente establezca una conexión WebSocket separada para cada cosa que quiera ver? Eso me parece un poco intensivo en recursos y no muy escalable. Si el cliente necesita ver 100 cosas, deberá mantener 100 conexiones WebSocket. Tenga en cuenta que la mayoría de los navegadores limitan la cantidad de conexiones WebSocket que pueden tener abiertas a la vez, tanto por página como globalmente.
Socket.IO es un protocolo de nivel superior que se basa en WebSocket y HTTP. Si aún prefiere usar WebSocket directamente, puede tomar cualquiera de los servidores WebSocket de código abierto disponibles e implementar su aplicación con eso en lugar de Socket.IO. Aquí hay algunas opciones para Python que tengo en mente:
- evento
- gevent-websocket
- websockets (asyncio)
- Tornado (asincio)
Vas a perder algunas cosas que ofrece Socket.IO que son muy útiles:
- Reconexiones automáticas
- Soporte automático para clientes que no son WebSocket a través de sondeos largos
- Despacho basado en eventos
- Habitaciones
Por lo tanto, debe asegurarse de que estas no sean características importantes, o está de acuerdo en implementarlas usted mismo directamente en el servidor WebSocket.