Stalker_RED

Не проверяется, разве в ваших книжках и видео не объясняется. И почему всё что рекомендуется обязательно должно быть про производительность.

Для передачи из одной записи в другую никакие транзакции нафиг не нужны.

UPDATE tablename
SET balance = balance + CASE WHEN userid = @sender
                             THEN -@amount
                             ELSE @amount
                             END
WHERE userid IN (@sender, @receiver);

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

1. Массивы индексируются с 0 а не с 1

randomInteger(1,6)

2. Проверка на проигрыш логически должна быть раньше чем запрос новой карты

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

const cards = [6, 7, 8, 9, 10, 11];

function randomArrayElement(array) {
  return array[Math.floor(Math.random() * array.length)];
}

function blackjack() {
  let sum = 0;
  while (sum < 22) {
    sum += randomArrayElement(cards);
    alert(`Ваше число на данный момент ${sum}`);
    if (!confirm('Возьмете еще?')) {
      alert(`Вы спасовали ваше число ${sum}`);
      return;
    }
  }
  alert(`Вы проиграли ваше число ${sum}`);
}

blackjack();

ИМХО, про Clickhouse незаслуженно забыли, если нужно хранить и какую-то аналитику использовать. А ведь он реально не тормозит, скорость сравнима с простым сбросом сырых логов на диск. Горячие данные на SSD или вовсе в памяти, во временных таблицах можно держать. Главное, батчами вставлять данные, но мелкие вставки ни одна база по моему не любит. Если для гарантированной доставки кафка или кролик будет юзаться - они нативно поддерживаются, но следует учитывать, что дополнительный слой == дополнительные просадки по времени.

если нужно хранить условно за час, то и вовсе стоит смотреть на Aerospike, да и вообще, если этот же час нужно держать в близком доступе, он будет полезен. его незаслуженно мало упоминают в русскоязычном сообществе, а по факту он на голову превосходит всякие редисы, даже бесплатная версия. А также он умеет в постоянное хранение, комбинированное и даже с диском, как с блочным устройством напрямую работать, без ФС

Инфлюкс - он и вовсе про другое, это временные ряды, метрики. Как и Prometheus и Victoriametrics

P.S.: не ради срача и троллинга, но все же староверов, которые в файловой системе хранить все предлагают, мне хочется спросить: Господа хорошие, а вы свои проекты наверно до сих пор храните в виде Новая_Папка, Новая_Папка1, Новая_Папка2 и т.д.? Нужно все таки смотреть на алгоритмы записи, работы с железом и прочее, они меняются и развиваются. Ваш, да и мой тоже 2007 не вернуть

Не вижу никакого смысла парсить частично, но если так сильно хочется:
JsonDocument
Utf8JsonReader
А вот так ими пользоваться:
https://docs.microsoft.com/en-us/dotnet/standard/s...
На dynamic даже не смотри, его поддержку из System.Text.Json вырезали

почему slick не является функцией?

Потому что ('.products__slider') - это просто строка, а у строки нет метода .slick