rPman

Для параллельных тяжелых вычислений нужно использовать воркеры или к примеру модуль child_process

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

т.е. у тебя УЖЕ есть сервер и тебе его просто запустить, открываешь документацию по этому серверу и работаешь (ее должны были написать те кто делал этот сервер), либо, если документации нет, изучаешь весь код

в документации по nodejs приведет сразу же пример простейшего веб сервера, ищи что то похожэее, смотри в каких файлах идет вызов и соответственно запускай этот код

p.s. есть практика размещать все необходимое для запуска приложения в настройках пакета, тогда запуск будет что то типа:

npm install
npm build
npm run-script start

Т.е. install установит и обновит зависимости проекта, build запустит скрипты подготовки и оптимизации (например webpack), в общем что указано разработчиками, ну и запуск run-script start

И конечно, если это сделать в каталоге проекта в терминале, то закрытие терминала все закроет автоматически, поэтому это нужно будет прописать в виде сервиса systemd или каким то другим способом, принятом в твоей ОС

Что значит сверять, давать ответ есть/нет? слово это строка с любыми символами (пробелы, знаки препинания) или набор букв на каком то языке с игнорированием регистра и вспомогательных символов (встречаются в других языках), а кодировка у файла?

Если просто строка без учета всего иного, то читаешь файл в память fs.readFileSync(filePath, 'utf8'); где utf8 - ожидаемая кодировка файла. Наличие слова в этой строке можно простым регулярным выражением new RegExp(`\\b${targetWord}\\b`, 'gi') и методом regexp.test(строка_с_содержимым_файла). Соответственно fs подключить require('fs').

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

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

Так же добавить к ссылке хеш 'от нее плюс секретную соль', или используй ассиметричное ее шифрование, чтобы не дать ее взломать

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

Мне кажется мочь запилить свой time-task-execute сервис должен каждый программист, начинающий карьеру.

99% работы по созданию своего сервиса - это управление временными интервалами, т.е. способ, с которым пользователь управляет своими задачами и задает время. Т.е. нет никаких проблем, чтобы сделать приложение, читающее конфиг (текстовые файлы или база данных, не важно) и организующее набор слипов (кода строк 5-10 где то - ищем ближайшую задачу, которая должна быть выполнена, делаем sleep на этот интервал, исполняем задачу, повторить).

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

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

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

Поэтому ответ:
- по первой схеме сервер отправляет клиентам с периодичностью информацию об итоговом изменении уровня жизней.
- по второй схеме сервер отправляет клиентам команду "начинайте увеличивать жизнь со скоростью X до уровня Y" и клиенты это выполняют, запустив свой таймер.
Для контроля состояний сервер может периодически высылать хеш своего состояния чтобы клиенты могли его сравнить со своим, если они различаются значит в коде баг (например неверно обрабатывается лаги) и как минимум нужна повторная загрузка состояния с сервера

никак

electron это браузер, и в нем мало сделано чтобы этот браузер не был похож на хромиум (есть эксперименты делать на основе firefox, без разницы), соответственно что бы ты не делал, чтобы все работало в результате должен быть браузер с его профилем и файлами.

гугли electron obfuscation, может что то тебе подойдет, для сокрытия и запутывания исходников

https://www.npmjs.com/package/websocket
смотри примеры client example

попробуй что тут написали

An alternative might be ( but more typing in the long run )

$ cd /media/sf_shared/myproject
$ mkdir /home/dan/myproject && npm install --prefix /home/dan/myproject
$ NODE_PATH=/home/dan/myproject/node_modules node index.js

не про конкретно это но это тоже важно

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

Так же, поставь mitm прокси и сравни ее дампы при использовании браузера и использовании твоего скрипта, как минимум обнаружишь свои ошибки

p.s. порядок параметров в запросе тоже может быть актуальным