Комментарии 5
Я бы включил режим максимальной паранойи.
Если пакеты от монитора не приходят в течении более чем полутора периодов, нужно бежать, орать, бить тревогу.
Если гуй не может допинговаться до бека в течении одной секунды — правильно, бежать-орать, выть сиреной
Если параметр резко скакнул — алярм.
Если бэк не видит свежих апдейтов в постгресе — алярм.
Если из сетевых интерфейсов полезли ошибки — алярм.
Если формат пакета нарушен — то же самое.
Короче, такая система должна быть увешана тестами, ассертами и проверками на все законы Мерфи, как атаман каракулем.
Если пакеты от монитора не приходят в течении более чем полутора периодов, нужно бежать, орать, бить тревогу.
Если гуй не может допинговаться до бека в течении одной секунды — правильно, бежать-орать, выть сиреной
Если параметр резко скакнул — алярм.
Если бэк не видит свежих апдейтов в постгресе — алярм.
Если из сетевых интерфейсов полезли ошибки — алярм.
Если формат пакета нарушен — то же самое.
Короче, такая система должна быть увешана тестами, ассертами и проверками на все законы Мерфи, как атаман каракулем.
Какая-то стремная цепочка. Широковещательные UDP пакеты поверх Ethernet как я понимаю — нет никаких гарантий что из-за коллизий пакет дойдёт вовремя, потом Go с GC, потом PostgreSQL у которого нет никаких жестких гарантий на время записи и наконец JavaScript с GC. Понятно что обычно все доходит и отображается вовремя, но как в такой сложной системе доказать что с момента обнаружения проблемы прибором у кровати больного до показа оповещения в дежурной комнате пройдёт точно не более X секунд?
По-моему дорогая цена у существующих систем, о чем сказано в начале статьи, оправдана.
В общем, индийский код в действии ).
Что то вы загнули про три дня, тут работы на три недели
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Go, Vue и 3 дня на разработку: система реального времени для мониторинга пациентов