Дмитрий Беляев

Сделать то можно, например так:

const moveQueue = {
  queue: [],
  index: 0,
  create() {
    let endMoveCallback;
    // создаём висячий промис и присваиваем его разрешение в endMoveCallback
    const movePending = new Promise(resolve => endMoveCallback = resolve);
    // index чисто для лога
    endMoveCallback.index = this.index++; 
    // добавляем в очередь
    this.queue.push(endMoveCallback);
    // возвращаем проис ждущий вызова endMoveCallback
    return movePending;
  },
  last() {
    // забираем из очереди последнее добавленное
    return this.queue.pop();
  }
}

async function turn() {
  await startMove();
  await startShoot();
}

function startMove() {
  console.log('startMove', moveQueue.index);

  return moveQueue.create();
}

function endMove() {
  const activeMoveEnd = moveQueue.last();
  if (activeMoveEnd) {

    console.log('endMove', activeMoveEnd.index)

    activeMoveEnd();
  } else {
    onsole.error('`endMove` called when there are no active moves')
  }
}

function startShoot() {
  console.log('startShoot');
}

turn();
setTimeout(() => endMove(), 1000)

Но скорее всего у тебя что-то не то с архитектурой, и тебе лучше будет почитать книжки по геймдеву.

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

Вот вы говорите:

Нужно будет выполнять много запросов к БД

Важная быстрая скорость работы нашего сайта

Много/быстро это сколько? 100 запросов в час? 1000 в минуту? 1М в секунду? Загрузка страницы за 30/10/1с или даже 100мс? А к какой именно БД? Какая характеристика самих данных и какого типа запросы? На какое количество соединений? В каком регионе? Есть ли там тяжелые или еще какие-то вычисления? Медиа файлы - картинки, видео? Тут очень много нюансов. В идеале следует определиться с конкретными значениями/параметрами и их описать в ТЗ. Ну или определить примерное, а фактическое значение определить на стадии прототипа/MVP и/или провести какое-то исследование/тестирование. Можно потратить десяток лямов на написание крутого кода на го/расте/С++/ассемблере в течении года и все будет летать на простейшем сервере. А можно купить свой сервер за лям (ну, условно, конечно), нанять питонщика или PHP-ника за 300к и он за пару-тройку недель добьется такого же результата. Большинство веб-задач сегодня достаточно просто или с минимальными усилиями решаются абсолютным большинством решений для веба. Да, у всех решений есть свои плюсы и минусы.

Безопасность от всяческих XSS и SQL атак.

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

А так - уже правильно посоветовали сразу брать дот-нет, т.к. у вас требование к использованию конкретной библиотеки для дот-нета.

Поменяй: props.item.office на 'office' in props.item.
Ты не можешь обращаться к свойству которого нет сразу во всех типах union'a. Но ты можешь проверить его наличие, а дальше ts, в зависимости от результата, сузит тип до того, в котором оно присутствует.

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

Вместо таких заявлений он должен подробно изложить исходную задачу.
Про которую ему подробно расскажут, как её решать нормально.

Хранить фото и видео в БД - это как надевать штаны на голову.
Хранить фото и видео в монге - как надевать на голову помойное ведро.

Файлы надо хранить в файловой системе.
Структурированные данные надо хранить в Базе Данных.
Монгу не нужно использовать ни для чего. Это вообще не база данных, а просто хранилище по типу "куча мусора", которое используется исключительно в стильных модных молодёжных стартупах, в которых не нашлось ни одного специалиста по базам данных. Это была тупиковая ветвь, поднявшаяся на отсутствовавшей на тот момент поддержке JSON в базах данных и хайпе

Первый и самый важный шаг вы сделали — идите дальше. Смотрите что у вас в document.getElementById('id').value, потом что в document.getElementById('id'), если в value пусто.
Это называется "отладка" или "дебаг" и это примерно половина работы программиста.

выводит новую форму

Вангую, что в итоге у вас куча одинаковых форм и, соответственно, куча инпутов с id="id", что, естественно, недопустимо.

Цифр больше 9 в десятичной системе не бывает.
А ваш код выдаёт числа от 1 до 10, как вы в нём и написали.

select for update

Это уже и так из коробки работает в терминале. Не нужно усложнять своё приложение этим.
Попробуй использовать shift+insert или ctrl+shift+v, если у тебя в терминале на ctrl+v пишется ^V.
Либо посмотри настройки.

Когда вы используете только одну функцию то кажется что он не нужен. Но что будет если вы используете цепочку методов? К какому массиву вы будете обращаться например в фильтре после трансформации массива?
arr.map(mapper).filter(filter).reduce(reducer)