Комментарии 20
Код - картинками, да ещё и serif-шрифтом...
Мы разрабатываем клиенты при помощи веб-технологий, с использованием фреймворка Angular.
Не самый лучший выбор, если вам нужно отображение больших объёмов данных данных в реальном времени.
При непрерывной работе клиента утечки накапливаются и могут привести к потере производительности, зависанию интерфейса, а в худшем случае – к out of memory браузера.
Поэтому важно, чтобы используемый фреймворк поддерживал автоматический контроль времени жизни ресурсов. Опять же, Angular это не поддерживает.
пусть при фактическом поступлении данных каждые 200 мс настраивается период троттлинга в 1 секунду. В этом случае данные за 1 секунду будут накапливаться, а обрабатываться будет только последнее значение, прочие значения будут игнорироваться. Интерфейс также будет перерисовываться не чаще одного раза в секунду.
Не знаю, что вы там такого рисуете, но не вижу проблемы перерисовывать интерфейс по мере поступления данных, то есть каждые 200мс в данном случае.
Для «тонкой настройки» обработки данных мы рекомендуем библиотеку RxJS. Библиотека позволяет манипулировать данными в функциональном стиле, в том числе ограничивать обработку данных с помощью троттлинга. А с помощью функции distinctUntilChanged библиотеки можно определять, что новые данные не отличаются от предыдущих, и за счет этого оптимизировать частоту обновления интерфейса и исключать «паразитные» перерисовки, когда данные не изменились.
Лучше всё же использовать системы реактивности, которые занимаются этим самостоятельно, а не требуют постоянной "тонкой настройки".
Опять реклама $mol? Непонятно только зачем. Ибо что ни тезис, то какая-то белиберда.
В статье не утверждается, что Angular единственно верный вариант решения.
Мы стремились описать такие кейсы, которые были бы применимы вне зависимости от используемой библиотеки или фреймворка.
Если ваш стек позволяет реализовать их из коробки, отлично!
А если вы работаете с Angular и вам потребовалось реализовать промышленный АРМ, то не унывайте. Мы собрали основные проблемы и вы можете закрыть их за 5 минут, пользуясь примерами выше.
Для логирования мы используем ELK и это очень удобно, посмотрите, может вам тоже подойдет.
Особенно, когда много сервисов, данных и логов.
В Kibana быстро набрасываются дашборды и отчеты.
Анализ ошибок и сопровод сильно упрощаются.
Бизнесовые метрики также можно завернуть на Elastic.
И в целом я стремлюсь к минимизации сторонних фреймворков до предела. Потому что одно дело — быстро накидать работающее решение, и совсем другое — обеспечить ему надёжность и кувалдоустойчивость. Ну и события последних дней показали, что импортозамещение — не такая уж и бредовая идея.
Ничего личного, но для систем реального времени есть специализированный софт и разрабатывать вот это все, с моей точки зрения и опыта, смотрится как - "Мы выиграли тендер в России, но бюджет был недостаточный для покупки SCADA-системы и решили сделать это все на web'е". Может я конечно и утрирую, но в нефтянке вот это все бы точно не прокатило...
Дело в том, что просто взять и внедрить SCADA никто не даст, даже если бюджет такое позволит.
У предприятия есть безопасность, существующие тех процессы и тех инструкции, системы всех уровней автоматизации от L2 до L4. Получить разрешение на изменение этих систем или внедрение новых это проект совершенно другого уровня и бюджета, как вы верно заметили.
К тому же в статье речь об оптимизации работы лишь нескольких агрегатов одного цеха, это не автоматизация производства или даже отдельного участка. На соседнем агрегате работает аналогичная система китайских "коллег", сделанная на .Net и мы конкурируем.
Для SCADA это слишком локальная задача, если бы мы ее решили таким образом, уверен, нас бы упрекнули в том, что мы внедрили SCADA для задачи, которая решается парой микросервисов :) я утрирую, но думаю суть понятна.
P.S. Я бы не сказал, что у нас система реального времени. Да, мы выводим медиа на фронт в реальном времени, но это вершина айсберга.
Надёжнее было бы проверять не попадание в конкретную секунду, а день — просто сохранять предыдущую цифру дня и по таймеру проверять, изменилась ли она.
Хотя конкретно с Хромом, location.reload() всё равно не сильно помогает. Можете сами убедиться через диспетчер процессов shift+escape, что когда вкладка начинает занимать кучу памяти, простым F5 это не лечится, а вот открытием новой вкладки и закрытием старой — вполне. Средствами JS это кроссбраузерно не сделать, так что можно либо написать несложный плагин к браузеру, либо инструкцию пользователю.
Это надо делать не плагином и не инструкцией, а средствами планировщика ОС.
Вы правы! По изменению дня обновлять страницу было бы надежнее. Добавлю в статью уточнение.
На этот случай у нас есть дополнительное обновление страницы не из приложения. В статье это не описано, но мы также обновляем страницу средствами ОС. При установке киоска есть возможность настроить автоперезагрузку страницы.
Можно настроить и рестарт браузера, но с этим проблем становится только больше.
Вот из-за таких проверок и говорят потом, что Ангуляр педальный
JSON.stringify(x) === JSON.stringify(y)
Не нужно так делать, это же данные из сокета, проще на бэке проверять изменение данных и только потом пушить, чем вот так воздух греть на клиенте
Простите, но причем здесь Ангуляр?
Да, мы можем слать одинаковые данные клиенту, так устроена архитектура.
Как разработать фронтенд, чтобы не ночевать на заводе