Приложение для визуализации инженерного объекта

Нужно разработать frontend-приложение для визуализации инженерного объекта (например, здания или дома), на плане которого может отображаться до 20 000 устройств (KNX, DALI, Modbus и другие системы).

Опишите, пожалуйста:

Какие вопросы вы задали бы заказчику на первой встрече, чтобы собрать требования?

Чтобы собрать требования на встрече с заказчиком я бы задал следующие вопросы:

Какие допущения приняли бы, если ответы пока получить нельзя?

Я бы предположил, что это будет веб-приложение, состоящее условно из двух частей: просмотрщика и редактора. Редактор нужен для добавления информации в систему, просмотрщик для просмотра конкретного инженерного объекта. Для каждой части требуется аутентификация.

При этом каждый аутентифицированный пользователь может просматривать информацию, но не каждый обладает правами на редактирование.

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

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

Как бы вы построили высокоуровневую архитектуру frontend-приложения?

Исходя из допущений приведённых выше я бы построил архитектуру следующим образом:

Просмотрщик

Прогрессивное веб-приложение (PWA) с возможностью оффлайн-работы и кэшированием, оптимизировано под мобильные устройства.

План представлен как масштабируемое изображение с векторным или растровым фоном. Устройства — точечные маркеры поверх него.

Примерная функциональность:

Редактор

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

Примерная функциональность:

Какие технологии и почему вы бы выбрали?

Для просмотрщика я бы предложил максимально использовать нативные возможности платформы: ванильный джаваскрипт, веб-компоненты, воркеры. Для рендеринга плана и устройств использовать Canvas или WebGL.

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

Для редактора используется любая из современных популярных библиотек (React, Vue, Svelte, Angular и т.д.), чтобы обеспечить удобство и скорость разработки.

Какие основные риски видите в таком проекте?

Основные риски в этом (да и любом другом) современном веб-проекте следующие:

Производительность и рендеринг

Из-за большого количества устройств (до 20 000) их отрисовка в браузере может вызвать зависания и падения FPS, скорее всего их одновременная отрисовка (в том числе и на Canvas) технически невозможна. Нужна виртуализация и кластеризация результатов.

Зависимости

Из-за нестабильности интернета серверы систем CI/CD могут терять связность с репозиториями типа npm. Это может ломать сборку.

В целом использование большого количества неконтролируемых зависимостей опасно из-за возможных атак на цепочку поставок (см. случай с Shai Hulud, случай с node-ipc).

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

Использование неконтролируемой PKI-инфраструктуры

Новость последних нескольких дней: у банков перестали работать сертификаты. Комментарии излишни.

Отсутствие контроля над конечной клиентской средой

Мы достоверно не знаем где и как будет запускаться наше приложение (на какой машине, в каком браузере и тд.)

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

Мы не можем контролировать ни одно из этих звеньев, а значит, должны быть готовы к множеству сценариев отказа.