Как отобразить данные реального времени на веб-интерфейсе максимально простым способом?

Дано: сервис, который собирает некие аналоговые данные и дискретные события в реальном времени.

Требуется: максимально простой способ отрисовать график и «лампочки» на веб-интерфейсе для демо, но имея в виду, что в дальнейшем понадобится миграция на профессиональное решение.

Сам сервис пишется на C (привязка к библиотекам), но возможна реализация RPC или REST API. Для платформы доступны также Python и Go.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

В azure есть готовые решения дл hot path stream аналитики.
Будет выглядеть так —
Ваш c клиент — event hubs(по rest api) — stream analytics(для агрегаций) — power bi.
Либо
C клиент — power bi(по rest api) если у вас там поток событий небольшой
docs.microsoft.com/...​ream-analytics-manage-job
docs.microsoft.com/...​pes-of-real-time-datasets

Можно попробовать с бесплатной подпиской.

Еще тут не упоминали SignalR — но под капотом там те же WebSockets. Учитывая бесплатность и кросплатформерность .net core тоже вполне может подойти.

Grafana + писать в какое-то хранилище вроде InfluxDB/ElasticSearch и не надо никакого UI городить.

и где тут система реального времени

  1. Формулировка. Мне кажется вам нужна система не реального времени, а близкая к реальной. С системами реального времени работают программы и счет там идет на миллисекунды, пример: биржевые боты, автопилоты автомобилей, и так далее. У вас же конечный пользователь человек, веб как никак. Задержку в 0.5-2 секунды вас вполне устроит. Верно?
  2. Подход — сквозная событийная модель реализованная с помощью реактивного программирование. Наиболее популярные реализации на разных языках — ReactiveX. В случае другого подхода вы не сможете иметь задержку сопоставимую с задержкой сети/реакции человека. Поддерживать вашу систему с таким подходом будет значительно проще, чем с объектной моделью.
  3. FrontEnd может быть реализован на любом из тройки современных фреймворков. Angular 2+ имеет под капотом RxJs, React нужно стоит брать вместе с Mobx вместо Redux или припиливать RxJs, аналогично Vue с Rx. Тут лучше смотреть по разработчикам. Для MVP можно брать даже PureJS.
  4. Протокол коммуникации server<->client очень важный вопрос. Учитывая плотный поток данных вам он нужен один протокол на обновления и на получения начального состояния. То есть забрать начальные данные по REST, и сделать подписку по WS нельзя. У вас будут или дублироваться события или терятся.
    Если у вас поток данных только от сервера, то берите SSE. Он отлично работает и решает проблему подписок, синхронизации состояния ложиться на протокол. Только убедитесь, что сможете прикрутить http2 без него легко упереться в ограничение количества соединения между браузером и сервером.
    Если нужен двунаправленный поток, то вам WebSockets.
    Подробней habr.com/post/120429
  5. BackedEnd любой технологический стэк для реализации веб сервера с поддержкой WS/SSE и интеграции с C кодом по сокетам. Определитесь, можете ли вы терять события. Это подскажет, что будет у вас single source of truth о прошедших событиях — какая-то база данных или in memory веб-сервера. С помощью RxGO/RxPY можно будет легко агрегировать события для отдачи на FE.
    Вы в списке почему-то не указали мой любимый Node.js. Я бы рекомендовал рассмотреть и его. Там удобные Stream для реактивного программирования.
  6. Масштабирование, если оно конечно потребуется, необходимо будет делать с использование Event Bus паттерна, то есть внедрять RabbitMQ, Nats и производить рапределиние потока событий уже через них
Система реального времени (СРВ) — это система, которая должна реагировать на события во внешней по отношению к системе среде или воздействовать на среду в рамках требуемых временных ограничений.
...
Следует заметить, что определение жёсткого реального времени ничего не говорит об абсолютном значении времени отклика: это могут быть как миллисекунды, так и недели
Дальнейшее не комментирую.

я так понял. что сама система пускай и реального времени, но забирать нужно данные _с нее_, т. е. данные с системы реального времени. т. е. вебка ее частью быть не должна.

заебен%те логгирование в текстовый файл вашего формата ака буфер и забирайте на веб максимально простым протоколом. после рисуете сшиваете и получается лог и график. можна даже без либ делать на с например а график в flotr2 нарисовать

Я уверен, такие решения и в проде можно найти. Жесть, конечно. Так и стриминг логов можно реализовать через файлстрим.

tail -f huge.log | вебсокет_куда_надо )

можно дальше пойти и поднять любую подходящую дб на веб.. и отдельно к нему по рест уи крутить. получится быстро, не больно! и модульно

Да, как-то ELEKS рассказывали как они poll`или кассандру для подобной задачи. Все шустро работало. Но я бы пробовал сначала реактивный подход.

я подобное делал как-то, но с монгой в lxc. думаю до сих пор крутится

На фронте plotly.js, фреймворк на ваш вкус, забирать данные или по REST API (делать запрос каждые 15 сек, например) или смотреть в сторону веб-сокетов. Но учитывая что это для демо — проще будет наверное REST API. Только зависит от того как часто нужно обновлять график. Если каждую секунду — веб-сокеты.

Есть пет проект, бесплатный https веб сокет сервер, если надо погонять — есть возможность конектиться и работать.

бесплатный https веб сокет сервер

это многого стоит ))

шутки шутить изволите? :D

Для графиков взять вот эту библиотеку (там примеры есть на чистом жс). Потом делаете серверную часть простую, которая будет например по адресу /api/chart отдавать массив с данными в json. Каждые несколько секунд делаете запрос и перерисовываете график. Как по мне, то опрашивать сервер даже каждую секунду не проблема, если это демо для одного-двух-трех человек, а не 1000 клиентов сразу одновременно. Для этого можно использовать jquery и setTimeout — пишете рекурсивную функцию которая делает запрос, при получении ответа перерисовывает график с помощью Plotly.purge/Plotly.plot и вызывает сама себя через 1000мс при помощи setTimeout. Это самая простая реализация без фреймворков.

А вот в дальнейшем если предполагается много клиентов, смотрящих на графики, то нужно использовать сокеты. Но по сокетам не подскажу — сам ними не пользовался.

мне кажется проще забирать данные на веб самим сервером а потом раздавать какому угодно количеству. т. е. б2б:
датчики -> веб-клиент — обработка — > вебморда — > клиенты
зато не свлится от количества

Если нужно одностороннее соединение (отображение графиков, логов) идеально использовать SSE (Server Sent Events) или даже обычный стриминг. Можно также посмотреть в сторону long polling, или даже обычного polling.

Websockets подойдут, если нужно еще получать ответы от клиента в реальном времени.

Вкратце можно почитать тут habr.com/post/120429

Server Sent Events

Круто, не слышал про такой API. Но Edge не поддерживается.

Лайк за правильную статью

Думаю, щось таке мало б підійти:
medium.com/...​hon-tutorial-dba5255e7f0e

вебсокеты. реальным временем оно не будет из-за задержки соединения

никак — интернет не система реального врмени

А кто сказал, что здесь присутствует Интернет? В худшем случае 1G линк на соседний хост.

и каким боком тут less и sass? и чем ангуляр тут лучше обычного яваскрипта который будет работать на два порядка быстрее? Вы перечислили четыре не самых простых и главное, нафиг ненужных для данного вопроса технологии и назвали это «не заморачиватся». Пробуйте хоть иногда мозги включать

Максимально просто — дергать бэк по setInterval. Но это нехорошо, лучше уже сокеты.

пожалуй поддержу, но желательно знать скорость потока данных

Обычное логирование. Т.е. дискретность порядка десятков миллисекунд.

Наскільки багато даних треба показувати? Бо можна й фронт зафлудити за три секунди..

Пара аналоговых параметров и факты их выхода за предельные значения.

Тоді краще попередньо обробляти їх на стороні сервера, на UI вже можна кидати готові для споживання/рендерінгу дані.
Можна й без новомодних фреймворків та протоколів обійтися, хоч на jQuery наклепати. В якості протоколу використати AJ (Asyncronous JavaScript), коли UI періодично міняє src у тега script з певним id, браузер лізе звичайним GET за «даними», у відповідь приходить jQuery скрипт, який оновлює контент в деяких нодах. Тупіше не придумати.

Я правильно понимаю, что браузерный скрипт откроет соединение с сервисом и будет его опрашивать дергая REST?

Сервер будет пушить данные на клиент — реактивная модель.

Підписатись на коментарі