smilingcheater

Вопрос в том, какую технологию, библиотеки или алгоритмы выбрать под эту задачу?

У тебя описан простой фильтр. Реализовывается на любой "технологии".

насколько оптимально такое решение?

Представление в Постгрессе - чисто динамическая конструкция. Т.е. указанный запрос будет выполняться заново каждый раз, когда запрашивается его информация. С другой стороны, используемые таблицы достаточно компактны и почти стопроцентно кэшированы, так что вряд ли это может заметно сказаться на производительности.

Если запросы следуют настолько часто, что нагрузка от них заметна, то возможным решением может быть хранение переопределённых данных. То есть с использованием указанного запроса создаётся статическая таблица, и все запросы на получение данных выполняются именно в неё.

Актуализация данных таблицы (точнее, её полный пересчёт) выполняется из триггерной процедуры на каждое событие изменения любой из используемых в запросе таблиц, если изменение связано с вашей системой (заодно можно выпилить оттуда не связанные с приложением записи). Поскольку работа по изменению указанных данных достаточно редкая по сравнению с запросами на получение данных, такая схема может дать определённый профит. Однако, поскольку процесс предусматривает полную очистку таблицы и заполнение её с нуля, следует избегать интерференции со стороны двух конкурентных процессов изменения. Для полной гарантии любые изменения следует проводить в изолирующей транзакции.

Хотя как по мне, следует отделить систему безопасности Постгресса от авторизации в приложении. Мнение по данному вопросу от Everything_is_bad в комментарии - это не сарказм, а весьма правильное замечание.

Обязательным nginx не будет, но он рекомендован большинству веб-проектам. Очень многие проблемы на себя берёт nginx, и вообще странно брать высокопроизводительный инструмент (Actix Web) и не позаботься о балансировке нагрузки (или вы хотите сами писать балансировщик?).

Добавлю свои пять копеек.
- публичные свойства $user и $name;
- функция init вместо конструктора класса;
- (холивар) использование синглтона Database вместо внедрения зависимости.

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

В вашем случае нет нужды использовать MobX, вы это и сами заметили, однако давайте представим ситуацию, в которой этот ваш таймер нужен не в этом же компоненте, то есть создаётся в этом, но прокидывается дочерним компонентам. Это может привезти к увеличению кода в программе и может затруднить её чтение. В вашем случае выше, вы могли бы использовать export const myTimer и использовать его в любой компоненте.

А почему вы решили, что строку с наимениванием агента нужно писать внутри круглых скобок, как аргумент navigator.userAgent?

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

SSH никаких особенных ограничений на ip-адреса не накладывает.
127.0.0.1 - это вполне допустимый адрес, к которому можно подключиться.

Ну давай по порядку:
1.

• 151.248.113.78 - вроде ок
  
• 127.0.0.1 - точно мимо, тк локалхост
  
• 194.85.283.12 - невалидный адрес. ipv4 - это четыре 8битных числа. 283 не входит в этот диапазон
  
• 192.168.15.2 - подозрительно похож на адрес в локальной сети
  
• 172.16.0.92 - аналогично
  
• 185.76.145.0 - подозрительно похоже на адрес подсети, но пока карандашом
  
• 10.55.84.56 - что-то подозреваем
  

2. Идём смотреть, какие адреса точно являются локальными

• 151.248.113.78 - не локальный
  
• 192.168.15.2 - Для использования в частных сетях. RFC 1918. Глобальная маршрутизация запрещена
  
• 172.16.0.92 - Для использования в частных сетях. RFC 1918. Глобальная маршрутизация запрещена
  
• 185.76.145.0 - не локальный
  
• 10.55.84.56 - Для использования в частных сетях. RFC 1918. Глобальная маршрутизация запрещена
  

Остаются всего два адреса:
151.248.113.78 и 185.76.145.0
Причём второй может оказаться невалидным, если подсеть /24