Расширение Flask REST API с помощью WebSockets

Question

В настоящее время я работаю над расширением моего существующего REST API, созданного с использованием Flask -RESTPlus с поддержкой WebSocket. Идея заключается в создании Web Thing Model совместимого Web Thing (шлюза). «Вещи» в моем сценарии использования динамически добавляются или удаляются.

Текущая настройка позволяет потребителю получать последние значения из Thing, например датчик температуры, используя HTTP-запрос GET к / thingId / свойства / температура . В действительности значения потребляются из Kafka и временно хранятся в Redis.

Теперь мне интересно, как я могу расширить эту настройку и позволить потребителю не только опрашивать последние значения, но и подписываться на свойство Thing используя WebSockets. У меня есть рабочее решение, в котором я создаю «Комнаты» для каждого свойства, но для этого требуются два отдельных сервера и дублирование конечных точек.

Для REST у меня есть

@app.route('/<thingId>/properties/<propertyId>')
    # get latest datapoint
    return latestDatapoint

Для Flask -SocketIO у меня есть

@socketio.on('join')
def on_join(data):
    username = data['username']
    room = data['room'] # e.g. /thingId/properties/temperature
    join_room(room)
    send(username + ' has entered the room.', room=room)

, а затем я пересылаю данные в нужную комнату, как они поступают от Кафки. На стороне клиента мне нужно подключиться к серверу WebSocket и присоединиться к комнате

socket.on('connection', function(socket){
  socket.emit('join', 'some room');
});

Эта реализация работает, но я очень надеялся на альтернативный рабочий процесс, как показано на рисунке ниже, где клиент подключается к та же самая конечная точка, используемая в REST API, но с протоколом WebSocket вместо присоединения к комнатам и т. д. c.

Есть ли у вас какие-либо идеи, если это уже существует или возможно осуществить?

Answer 1

У меня есть рабочее решение, в котором я создаю «Комнаты» для каждого свойства, но для этого требуются два отдельных сервера и дублирование конечных точек.

Сервер Socket.IO и ваш HTTP-сервер не обязательно должны быть отдельными, во всех поддерживаемых конфигурациях вы можете размещать приложения HTTP и Socket.IO на одном сервере.

Я также не вижу дублирования конечной точки, но, возможно, это потому, что вы думаете о Обработчики событий Socket.IO являются конечными точками, хотя на самом деле это не так. В Socket.IO существует единственная конечная точка в смысле HTTP, поскольку весь трафик Socket.IO c передается по одному URL-адресу. Ваши обработчики событий - это просто функции, которые вызываются, когда в конечной точке Socket.IO появляются определенные события.

, где клиент подключается к той же конечной точке, которая используется в REST API, но с WebSocket. протокол вместо присоединения к комнатам и т. д. c.

Итак, вы хотите, чтобы ваш клиент установил sh отдельное соединение WebSocket для каждой вещи, которую он хочет наблюдать? Это кажется немного ресурсоемким и не очень масштабируемым для меня. Если клиенту нужно просмотреть 100 вещей, ему нужно будет поддерживать 100 соединений WebSocket. Имейте в виду, что большинство браузеров ограничивают количество соединений WebSocket, которые они могут открывать одновременно, как на странице, так и в глобальном масштабе.

Socket.IO - это протокол более высокого уровня, который построен поверх WebSocket и HTTP. , Если вы по-прежнему предпочитаете использовать WebSocket напрямую, вы можете взять любой из доступных серверов WebSocket с открытым исходным кодом и внедрить свое приложение с ним вместо Socket.IO. Вот несколько вариантов для Python вне моей головы:

• eventlet
• gevent-websocket
• websockets (asyncio)
• Tornado (asyncio)

Вы потеряете несколько вещей, которые Socket.IO очень удобные предложения:

• Automati c переподключения
• Automati c поддержка не-WebSocket-клиентов с помощью длинного опроса
• Диспетчеризация на основе событий
• Комнаты

Таким образом, вам нужно убедиться, что это не важные функции, или вы можете реализовать их самостоятельно непосредственно на сервере WebSocket.