VoidVolker

Проксируется в целом ровно точно так же, как и любая сетевая нагрузка: клиенты [n] -> балансер -> сервера [m]. Лимит портов в 65к достаточно просто преодолевается путем добавления дополнительных сетевых адаптеров/каналов.
Дополнительные ссылки:
https://unetworkingab.medium.com/millions-of-activ...
https://blog.postman.com/postman-engineering-milli...
https://serverfault.com/questions/725224/how-to-ha...
https://josephmate.github.io/2022-04-14-max-connec...
https://github.com/eranyanay/1m-go-websockets
https://github.com/ramsicandra/1million-ws

Кроме того, WS коннекты можно балансировать как HTTP - банальным редиректом на прямой коннект к серверу. Т.е. клиент коннектится к балансеру, а он ему говорит: "а теперь тебе вот сюда коннектится надо". Или можно совмещать. Пару слов про проксирование WS в nginx: в сети пишут, что nginx с этим плохо справляется под существенной нагрузкой и лучше всего проксировать WS через специализированные прокси типа HAProxy.

Складывать их в какое-то хранилище и после манипуляций с апи crm обрабатывать или есть более подходящие решение?

Да, складывать. Называется это "очередь". Используйте Redis, RabbitMQ и прочее.

То, что вам нужно называется "пользовательский скрипт". Используйте расширение типа TamperMonkey. Если хотите автоматизировать именно сам сайт - то вам следует использовать сетевую библиотеку для веба в любом знакомом вам ЯП для использования API сайта. У любого открытого API есть документация с примерами - используйте её для написания кода. Если там нет открытого API, то проще всего взять что-то типа Selenium или NWJS. Если не знаете как, то вам на фриланс.

Попробуйте в свойствах exe самого приложения поставить галочку "запускать от администратора" в разделе для всех пользователей. Если не поможет, то смотреть настройки встроенного автозапуска - как именно оно запускается. Оно может в реестре запускаться, может как сервис, может в планировщике, может через "автозапуск" в меню "пуск".
https://github.com/MatsuriDayo/nekoray/issues/208 - там в топике такая же проблема, но в линуксе - решено было добавлением прав для исполняемого файла. Так что должно сработать и под виндой.

Да, можно. Используйте wget или curl:
ssh user@server wget https://test.com/arhiv.rar
ssh user@server curl https://test.com/arhiv.rar

А открыть мануал приложения вам религия не позволяет? RTFM: https://ahk-wiki.ru/send

Легко - ставите расширение TemperMonkey и добавляете следующий скрипт в него:

// ==UserScript==
// @name         Исправление текста
// @namespace    http://tampermonkey.net/
// @version      2024-10-22
// @description  Заменяет все английские буквы во всех текстах на русские
// @author       VoidVolker
// @match        https://24forcare.com/*
// @icon         https://www.google.com/s2/favicons?sz=64&domain=24forcare.com
// @grant        none
// ==/UserScript==

;(function () {
    'use strict'
    $(function () {
        console.log('Скрипт запущен в работу...')

        // Английские символы
        let en = 'ABCEHKMOPTXYabcehkmoptxy'
        // Русские символы
        let rus = 'АВСЕНКМОРТХУавсенкмортху'
        // Таблица замены en -> ru
        let map = {}
        en.split('').forEach((char, i) => (map[char] = rus[i]))

        // Счетчик замен
        let charsCounter = 0
        let nodesCounter = 0

        // Нормализовать текст
        // В идеале следовало бы извлечь из текста слова
        // И уже в словах проверять наличие разных символов 
        function normalizeEn2Rus(str) {
            // Конвертируем строку в массив
            let arr = str.split('')
            // И проходим по всем символам в массиве
            for (let i in arr) {
                // Получаем символ
                let char = arr[i]
                // Если символ найден - заменяем его, если нет - оставляем оригинальный
                arr[i] = map[char] ?? char
                charsCounter++
            }
            // Конвертируем массив в строку и возвращаем результат
            return arr.join('')
        }

        // Получаем список всех элементов на странице
        let items = $('*', document.body)

        // Проходим по всем элементам
        items.each((i, item) => {
            // Исключаем ссылки, скрипты и стили из поиска
            if (item.nodeName === 'A' || item.nodeName === 'SCRIPT' || item.nodeName === 'STYLE') { return }
            // Получаем список детей у элемента
            Array.from(item.childNodes)
                // Фильтруем только текстовые элементы и те, в которых есть текст
                .filter((el) => el.nodeType == Node.TEXT_NODE && el.textContent?.length > 0)
                .forEach((el) => {
                    // Нормализуем текст элемента
                    el.textContent = normalizeEn2Rus(el.textContent)
                    console.log(el.textContent)
                    nodesCounter++
                })
        })

        console.log(`Скрипт завершил работу успешно. Всего заменено символов [${charsCounter}] в [${nodesCounter}] текстовых элементах.`)
    })
})()

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

Если он подходит по размерам и ТТХ - то вполне можно, почему нет-то?

Да, конечно можно проверить работу каждой фичи и функции ручками. Это если у тебя три-пять фич/функций, ну десяток еще можно, а изменения - раз в неделю. А если это надо делать на каждый коммит? Десять коммитов в день? А как проверять, если там 100 экранов, на каждом экране по сотне графических элементов, у которых по пять состояний в различных вариантах, два десятка эндпоинтов в бэкэнде, а в коде паутина из 10-100к функций и хрен знает сколько зависимостей? Итого 100 x 100 x 5 x 20 - уже миллион вариантов. Ой, а у нас там еще есть отдельная админка для этого вот всего, биллинг, мониторинг, отчеты, интеграция с тремя десятками платёжных систем и бакнов, почта, интеграции с мессенджерами, кэширование, резервирование, бэкапы и еще пара сотен зависимостей и интеграций с другими системами. Сколько месяцев или даже лет ручного труда потребуется для ручной проверки работы такого проекта в каждом коммите за время работы команды из десяти разработчиков в течении хотя бы одной недели?

Возьмём для примера обычный виндовый калькулятор: 4 варианта - 40 элементов интерфейса только в одном только обычном варианте, в статистике - примерно 50, в инженерном чуть больше сотни, в режиме программиста - все две сотни. И у каждого элемента в среднем от одного до десяти состояний, плюс еще связи с другими элементами, а так же разное поведение, зависящее от других элементов. И работу каждого элемента надо проверить с учетом всех возможных вариантов его работы. Сотни и тысячи фич/функций, десятки и, вероятно даже сотни, тысяч вариантов. Да, конечно, большая часть всего этого перекрывается более высокоуровневыми тестами и переиспользованием уже написанного кода (что, кстати, как раз и создаёт все эти зависимости) и тестировать под сто раз одно и то же нет необходимости. Но вот так, вручную, без конкретного списка конкертных фич и автоматизации - как проверить правильность работы хотя бы вот такого обычного калькулятора?

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

А еще есть такая методика, как TDD: разработка через тестирование - сначала создаётся тест на фичу, а уже только потом создаётся сама фича.

Подойдёт ли Windows Forms? Мне ведь потом на мобилку порт делать.

Формы - это .Net и только для винды. Причем это уже очень старое легаси, которое имеет смысл использовать только для поддержки Windows XP - а у нас тут уже поддержка 10 заканчивается так-то. А .Net - это прежде всего C#. И вот на C# есть более новый WPF и кроссплатформенный MAUI. Для мобилки все равно придется переписывать с нуля или искать какие-то варианты решений, которые могут C# в мобилки.

Или на мобилку лучше не на C++ делать? Что посоветуете?

Не самое лучшее решение - там родная платформа Java и Swift. Qt умеет: https://doc.qt.io/qt-6/mobiledevelopment.html - но как оно там в результате будет работать сложно сказать и можно ожидать каких-нибудь слабопрогнозируемых глюков и сложностей. Спасибо Adamos.

Может кому-то известны нюансы при постройке такой программы?

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

В общем, у вас несколько вариантов. Вариант раз: если хотите именно плюсы - то вам следует использовать Qt и писать код сразу с учетом дальнейших доработок для работы в Linux, Mac и на мобилках - не знаю, как и на сколько хорошо Qt умеет в мобилки, но могут быть какие-то сложности/баги. Ну, в кроссплатформе от этого не уйти - придётся мириться и местами писать разный код для разных платформ.

Вариант два: если хотите сразу писать приложение сразу для всех платформ с единой кодовой базой и минимальными услиями - то можно использовать веб-платформы типа NWJS, Cordova и прочие браузерные платформы. Минус - приложение будет тяжёлым и ощутимо более медленным, чем нормальное нативное.

В целом, могу рекомендовать для начала просто сделать на плюсах с Qt хоть какое-то приложение для винды, далее внести доработки для работы в линуксе и маке. При наличии/доступности мака - можно сразу и для мака делать. Линукс прекрасно ставится и работает в VirtualBox и прочих виртуализаторах. Далее сделать поддержку сетевых фич, БД и прочего, а уже только потом переключаться на разработку для мобилок. При этом, вам надо будет организовать свой план разработки от меньшего к большему. Т.е., сначала самые простые функции делаете, а уже потом к ним добавляете что-то более сложное по мере изучения.