VoidVolker

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

Для подключения к серверу используется SSH. Настраиваете SSH, подключаетесь к серверу, устанавливаете на нем ноду. Наиболее правильный вариант: настроить на сервере автоматический деплой c гита (гитхаба, гитлаба, битбакета и т.п.) используя SSH ключ для деплоя. Чуть более простой вариант: настроить SSH ключь для деплоя из гита, далее просто заходите на сервер и ручками обновляете приложение и перезапускаете.

Да, имеет смысл. Отличнейшая рабочая машинка. Производительность и автономность на высоте. Единственный серьезный минус - очень слабая х86 виртуализация, в 10 раз примерно медленнее в сравнении с АРМ виртуалками (проверял в UTM), в докере х86 машины тоже ощутимо медленные.

В свернутом окне сделать клик можно только если это окно считывает клик из сообщений окна и только если это в винде, в других ОС системное API немного по-другому работает. Все, других вариантов нет, кроме как взлома самого процесса игры. Большинство игр, особенно трехмерных, используют различные API для работы с пользовательским вводом - в некоторых случаях эмуляция проходит через эти API, в некоторых - нет. А еще в играх, особенно в онлайновых, предпринимают специальные меры для противодействия эмуляции ввода и читерам, что еще больше усложняет написание ботов для игр, но не делает это невозможным. Иногда достаточно стандартного API, иногда - нужен драйвер в ринг ноль, чаще - реверсинг и взлом самой игры.
Для начала надо определить, каким именно образом игра работает с пользовательским вводом и уже после этого искать возможность его эмуляции.

Как правильно разделить обязанности между фронтенд и бэкэнд разработчиками в 2022 году?

Сделать декомпозицию всего проекта в несколько интераций, далее правильно его структурировать и спроектировать архитектуру, которая будет решать поставленные перед проектом задачи и соответствовать его требованиям. Архитектуру разрабатывает/разрабатывают архитектор и/или тим- и тех- лиды. И вот когда на руках будет исчерпывающее ТЗ со всеми деталями - на этом этапе тимлид и прожект-менеджер создают задачи для фронт-энда и для бэкэнда. При этом, выставляются взаимосвязи и блокировки задач: например, "список пользователей в админке" для фронта, зависит от "базовое API для управления пользователями" для бэка, если задача для фронта требует каких-то дополнительных точек API - просто создается подзадача для бэка типа "поиск пользователя по всем полям учетной записи". И такие подзадачи не просто могут быть, они однозначно будут и надо просто учитывать этот момент.

То же касается и функциональности сортировки, фильтрации, поиска и так далее.
Есть ли смысл делать это все на сервере?

Конкретная реализация зависит от задач. Если данных мало и их можно быстро передать - то да, удобнее на клиенте обрабатывать, если данных много - то на сервере, при этом сделать кэш и группировку для горячих данных для ускорения. Приведу реальный пример из практики (тыц): была задача сбора и отображения статистики использования десятки терминальных серверов на нескольких сотен пользователей. От каждого активного пользователя по несколько сотен точек в день, десяток машин. И для каждой машины и для каждого пользователя надо было сделать график и чтобы все это можно было быстро и удобно просмотреть. Десятки и сотни мегабайт данных - сотни тысяч точек за несколько месяцев. На одной странице. Все данные хранятся в БД, горячие данные - в кэше памяти, аппроксимация точек для разных периодов времени за 3 месяца, быстрые фильтры для получения данных для построения графика с нужной точностью за выбранный период. Т.е., фронт говорит "дай данные за такой-то период для такого-то сервера/пользователя" - бэк быстро фильтрует нужное среди нескольких сотен мегабайт данных и отдает от нескольких десятков до нескольких сотен КБ.

Надо просто брать и решать реальные задачи. Например автоматизация действий за ПК или любые задачи, которые вам интересны. Или вот к примеру написать самый обычный калькулятор с использованием WPF и паттерном MVVM (например с либой Prism).

а как эти данные из джсона перенести в бд?

какой далее мой алгоритм действий

Очень просто:

1. Устанавливается и настраивается СУБД (в вашем случае для простоты подойдет MongoDB)
   
2. В серверной части устанавливается пакет Mongoose для работы с монгой
   
3. Пишете простой скрипт: загрузить JSON в память и сохранить данные в монго, используя Mongoose
   

Теперь в коде сервера спокойно подключаетесь к БД и используете её по назначению. Например, пишете классы по каждому типу данных, которые работают с БД. Для реализации API можно взять любую готовую библиотеку - их полно. И потом просто склеиваете это все вместе.

в целом трудность в понимании баз данных

Хороший повод пойти и почитать про основы БД, СУБД, как и зачем это все придумано и используется, а так же какие задачи оно решает.

Можно ли найти конфигацию с M1 PRO 32 ram

Да, в магазине эппл на этапе выбора конфигурации ноутбука есть возможность выбрать объем памяти 16/32ГБ:
https://www.apple.com/shop/buy-mac/macbook-pro/16-...
Кроме того, на странице описания ноутбука есть описание доступных конфигураций.

Если нет, хватает ли 16гб для задач когда требуется запускать пару докер контейнеров? Спасибо

Да, на десяток простых контейнеров хватит типа ноды, редиса, монги. А вот если контейнерам надо много памяти - то само собой не хватит. Лучше брать версию на 32 гига. И учтите, что виртуализация х86 очень медленная - в UTM c qemu в десять раз медленнее арм виртуалки, в докере не замерял, но по ощущениям примерно так же.

1. Почистить от пыли
   
2. Заменить термопасту
   

Нет доступа к порту.

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

Нет. Нагрев роутера вызывает какие-то проблемы? Зависает, тормозит и т.п.? Если да - то очевидно проблема в роутере, которая решается либо обращением к производителю/сервис (если это брак, например и он на гарантии) либо простой заменой роутера на более производительный. Ну или просто прилепить радиатор. Если проблем нет - то и незачем придумывать решение несуществующих проблем.

Например Deel. А пионер - пинайте ТП, там они медленные слоупоки просто.