Persotr27

для каждой такой игры, запускается свой инстанс сервера

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

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

Но если хочется именно выделять отдельный сервак под задачу, то надо писать софтину, которая используя API оркестратора, например Kubernetes, будет разворачивать целевые виртуалки из docker-образов, проводить им начальную настройку и маршрутизировать на неё клиентов.

ffmpeg на сервер установи и храни только MP4. Сейчас разные форматы уже не актуальны, а устаревшие браузеры , как и flash, давно не поддерживаются.
На 2013 год это да, был бы актуальный вопрос. Сейчас - нет.

Да, конвертировать на сервере.
Или заранее или "на лету" (дешевле по диску, но дороже по процессору/видеокартам.

Будет тормозить. Впрочем если применять не к месту - тоже будет. Где к месту, а где нет? А только v8 знает. Ты должен быть человеком - компилятором, чтоб оптимизировать React.

Можно ли написать относительно здоровое нормально функциорующее приложение, без применения этих тулзов, или зависать будет?

Можно. 90% веб-приложений оно нафиг не нужно.

Если type и subtype - строки, то можно так:

type CreatureBasis = {
    People: {
        child: {
            age: number;
            school: string;
        };
        adult: {
            age: number;
            height: number;
            weight: number;
        };
    };
    Animal: {
        fish: {
            waterBody: string;
        };
        cat: {
            catchMouses: boolean;
        };
    };
};
type Creature = {
    [K0 in keyof CreatureBasis]: {
        [K1 in keyof CreatureBasis[K0]]: {
            type: K0;
            subtype: K1;
            params: CreatureBasis[K0][K1];
        };
    }[keyof CreatureBasis[K0]];
}[keyof CreatureBasis];

https://www.typescriptlang.org/play?#code/C4TwDgpg...
TypeScript создавался чтоб затипизировать любую дичь, которую можно встретить в динамическом мире JavaScript. Как следствие у него тьюринг полная система типов, из чего есть 2 следствия:
1. при должном усердии можно затипизировать любую хотелку
2. некоторые особо навороченные типы могут повесить тайпчекер

Только через "палку", для того она и нужна:

interface CreatureBase {
  type: string;
  subtype: string;
  params: unknown;
}

interface PeopleBase extends CreatureBase {
  type: 'People';
}

interface PeopleChild extends PeopleBase {
  subtype: 'child';
  params: {
    age: number;
    school: string;
  }
}

interface PeopleAdult extends PeopleBase {
  subtype: 'adult';
  params: {
    height: number,
    weight: number,
    age: number
  }
}

type Creature = PeopleChild | PeopleAdult; //...

const arr: Creature[] = [
  {
    type: 'People',
    subtype: 'adult',
    params: {
      height: 1,
      weight: 2,
      age: 3
    }
  },
  {
    type: 'People',
    subtype: 'child',
    params: {
      school: 'foo',
      age: 3
    }
  },
  {
    type: 'People',
    subtype: 'adult',
    params: {
      school: 'foo', // err
      age: 3
    }
  }
]

А обойти типизацию можно кастанув as any, или дважды кастанув в новый тип var as unknown as type. Но не нужно.)

Если Вы предполагаете, что нечто является единой сущностью, то должен быть ровно 1 источник истины, определяющий эту сущность. Типы - это источник истины о структуре Ваших сущностей. Если в двух приложениях Вы оперируете одними и теми же сущностями, то и типы для них должны быть едины, иначе это будет нарушением DRY. Но если по факту сущности разные, то даже если они выглядят одинаково, их нельзя объединить, иначе это будет нарушением SRP.

Что можно сделать если типы описывают единые сущности:
1. Если оба приложения живут в одном репозитории, то можно просто переиспользовать одни и те же модули в обоих приложениях. Можно даже сложить их в общую папку и прописать на нее алиас в tsconfig.json и в конфиге сборки.
2. Если приложение живут в разных репозиториях, то общий код можно вынести в третий репозиторий и подключить его через git модули
3. А если общий код еще и меняется редко, то разбить его на отдельные npm пакеты - хорошая идея. При этом не обязательно заливать его в публичный репозиторий или покупать у npm приватный, и даже свое зеркало ставить не обязательно (хотя и удобно). Можно просто запаковать пакет в .tgz командой npm pack, а потом устанавливать его из этого .tgz через npm i прямо с файловой системы или с любого http сервера. Кроме того npm i можно делать прямо из git репозитория в корне которого лежит package.json, но как по мне - это не очень хорошая затея, так как в git лежат исходники, а в npm пакете должен быть готовый к использованию (собранный) js код.
4. Ну и наконец, единый репозиторий так же можно организовать в несколько пакетов, используя npm workspaces и lerna.

UPD:
Надо ознакамливаться на что ссылаешься...
В русской википедии в статье про SRP понаписано много бреда, которого нет в английской версии.
Забавно, что подобно английской статье, в русской так же ссылаются на Роберта Мартина, который определяет данный принцип правильно (по крайней мере в тех его книгах, что я читал).
Это очень распространенное заблуждение (OMG, я кажется нашел, откуда все эти люди, что приходят на собеседования, понабрались этого бреда...)
Принцип единственной ответственности не про то, что код делает что-то одно или отвечает за что-то одно (какая вообще может быть ответственность у текста?).
Принцип единственной ответственности про то, что у каждой программной сущности есть ровно одно ответственное лицо, и только это лицо является источником изменений в коде этой сущности.

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

Стоит или нет - вопрос, сколько времени/сил она сэкономит и нет ли других решений данной задачи.

поделитесь источником, как быстро настроить для VS Code

ОК, гугл: eslint vscode
Не благодари )) Ну реально нет смысла копипастить.
А вот то, что при компиляции нет ошибок, это плохо и надо настроить сборщик.

лишь ошибки типизации которые не мешают компиляции

Если проект компилируется - то все типы сошлись. Если проект компилируется, а ошибка все таки есть - значит типы криво описаны.

Как проверять все файлы проекта на правильность типизации?

Скомпилировать проект.

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

И это хорошо. Если TypeScript LSP будет перепроверять весь проект на каждый чих, а не только открытые файлы, то писать что-то сложнее todo листа будет невозможно...

Знаю, существуют ESLint, TSLint.

Они тоже для статического анализа, но для немного другого. В VSCode они так же чекают только открытые файлы, из тех же соображений производительности.
TSLint устарел. ESLint ставьте отсюда: https://marketplace.visualstudio.com/items?itemNam...

ТУПО КИНУТЬ РАБОТНИКА.

Цель только одна - тупо кинуть работника. Если есть договор по ТК - интересы работника более-менее защищены, по крайней мере когда работодатель половине сотрудников два месяца вообще не платит - есть вариант хоть что-то с этим сделать.

В случае ИП - тут совсем другое дело. Совершенно. Потому что любые споры - это только суд. И суд заведомо никогда не выгоден одиночному работнику, тем более ИП. Почему? Потому что реалии ведения бизнеса в РФ.

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

У работника (ИП) своего юридического отдела на окладе нет.

Очень часто работодатель заведомо платить не собирается - просто говорит - "есть вопросы - судитесь". И тут ИПшнику любой адекватный юрист, если там сумма меньше 300К - 400К рублей скажет - не надо даже связываться. (Отдельная тема - если юрист заранее хочет ИПшника кинуть).

Почему не надо даже связываться? Потому что ИПшнику придётся оплачивать, возможно, более шести месяцев работы хорошо если только одного юриста, из своего кармана, и на это уйдёт хорошо, если 500К рублей. Работодатель же не платит ничего - у него юротдел на окладе.

Один из вариантов стратегии работодателя в этом случае - это максимально возможное затягивание сроков.

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

Добавим сюда факты:
1. если работодатель мошенник - договор составляют очень умные и дорогие бригады юристов, консультирующиеся с очень большой кучей людей. и скорре всего там есть куча лазеек не в пользу работника.
2. если работодатель мошенник - у него скорее всего есть поддержка вне правового поля. а это очень плохо - потому что что-то этому противопоставить очень сложно.
3. работника может кинуть юрист - работодатель заплатит юристу больше, в итоге юрист протянет время, пропустит какие-нибудь сроки, будет какая-нибудь неточность в документах, и позиция работника развалиться.
4. если даже каким-то великим чудом работник выиграет процесс - запросить компенсацию даже малой части расходов у него не получиться - так уж устроено российское законодательство - немалые деньги и тонны времени будут безвозвратно потеряны.

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

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

В общем ИП в России - это уровень ведения бизнеса. В России. Со всеми вытекающими.

Трудовой договор - это уровень небизнесмена, и защищать свои права в этом случае проще.

зачем так делается?

тупая экономия. Именно тупая. Нет денег на грамотного бухгалтера и попытка поиграть с налоговой в крысу.

Почему не оформлять человека как сотрудника компании, через трудовой кодекс

дорго, хлопотно, авось проканает.
Работодатель помимо ЗП сотруднику платит немалые отчисления в соцстрах (именно из соцстраха платятся больничные и декретные, работодатель давно за это не платит), немалые отчисления в пенсионный фонд. Там под 50 % набегает. А в случае работы с ИП ничего такого нет. Ну почти.
Только такие схемы налоговая очень быстро вскрывает и резко прикрывает эту малину. Блокировка всех банковских счетов, даже тех которые никак не связаны с работой -- это только цветочки. Можно попасть на опрос и на допрос в налоговой. Кстати, отмалчиваться и пенять на 51 статью Конституции там не пройдёт.

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

Минусы:
1. Если недоплатят - разбираться надо не через Инспекцию, которая обычно на стороне работника, а через суд, где уже не так однозначно.
2. Отпуска и прочего по сути нет.

Итого:
Имеет смысл связываться через ИП только если деньги СУЩЕСТВЕННО выше чем по рынку. Если в рынке или разница небольшая - нафиг-нафиг, тогда это не выгодное сотрудничество, а игра в одни ворота.

Плюсы:
Нет отчислений от работодателя, отсюда возможно более выгодное сотрудничество в финансовом плане для обеих сторон.

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

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

Грубо говоря, легальная минизация налогов и упрощение ведение дел.
Штатное расписание и ЗП - много гемора, бОльший процент отчисления налогов с ЗП и так далее.

Меньше проблем, меньше расходов.
Если принимать человека по ТК - его просто так не уволишь, и зарплату не задержишь, сразу накажут.
Человеку принятому по ТК надо каждый месяц начислять зарплату, удерживать налог, а это расходы на бухгалтера, кто-то же должен все это считать.

А с ИП обычный договор. Нет работы - не платишь деньги. Налоги он сам будет платить. Никакой ответственности.

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

в этом есть и плюсы, и минусы. для обоих сторон.