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

Нормально работает. Считается умножение переменных цикла. Содержимое фигурных скобок в f-строках - это спецификаторы форматирования. Всё это элементарные основы, подробно описанные в любом учебнике и документации.

f-строки - это способ подставить в строку значение переменной или выражения.
В фигурных скобках - выражение, чьё значение нужно подставить. После двоеточия идёт указание на то, как это значение вывести.
Например, f"{i:2d}" означает "выведи значение переменной i как целое число (d), и дополни его пробелами до ширины 2 знака".

Подробнее в документации на язык, ссылку тебе дали выше.

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

Нужно сделать так, чтобы "бэкэнд на тайпскрипт" не падал, а отдавал 500 конкретно косячному запросу и продолжал работу.
Например можно в простейшем случае - завернуть весь колбэк обработки запроса в try/catch (если там есть асинхронные операции без await или блока .catch в Promise - то их внутренности тоже завернуть, содержимое каждой функции по отдельности).
Эксепшен не должен вываливаться до верха стека вызовов.

Потому что она реализует то, чего нет в стандартной библиотеке - асинхронный рантайм. Если писать сетевое приложение без токио, то придется плодить по отдельному потоку на каждый сетевой коннекшен. (на самом деле, речь идет про любой i/o, к которому чтение/запись файлов тоже относится) Каждый из этих потоков большую часть времени будет заблокирован в ожидании завершения сететвого вызова (передачи или приема данных). Однако, операционная система при разблокировке этих тредов будет постоянно переключать контекст для каждого потока и тратить процессорное время.
Асинхронный подход позволяет обойтись лишь сравнительно небольшим пулом потоков, на которые токио рантайм будет распределять таски (грин треды) и, таким образом, экономить процессорное время.

А что, стрелочные функции не принимают аргументов или не возвращают результат? Или делают это как-то иначе? Или они не являются функциями?
Вопросы риторические.

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

супермозговывертный вызов можно сократить до
console[level].apply(console, argsWithFormat)

console[level] - некая функция из консоли, например, console.error. Но в IE9 у неё нет apply, и вызов через точку не сработает. Потому берется стандартный Function.prototype.apply и вызывается через call, так что console[level] станет для него как this (как то, что перед точкой), а остальное - аргументами.

Да, в общем-то русским (английским) по черному написано - data_process.c включает data_process.h, который первым определил функцию normalization().
А потом сам data_process.c определил функцию normalization() чуть пониже - ессно компилятор выдает замечание о переопределении, ибо оно есть :)

Похоже на какие-нибудь циклические инклуды.
У вас в data_process.h случайно не включается data_process.c?
Так делать не надо.

СУБД на стороне клиента разработчику нужно воспринимать только в качестве разновидности кеша данных, для которого по счастливому случаю предусмотрен API в виде SQL.
Какие проблемы?
- Все те, что есть у любой подсистемы, что обеспечивает кеширование. То есть, нужно следить, чтобы в ней находились только актуальные данные. Обеспечивать своевременную синхронизацию данных с сервером, решать конфликты кеша и данных сервера. Если у вас для пользователя предусмотрено ведение учетной записи, то в локальную базу данных не должно загружаться никаких данных, не предусмотренные правами доступа пользователя.

В любом случае, у вас эксклюзивная часть приложения, в которой, например, ведутся сведения об учетных записях пользователей, хранится состояние лицензий, должна находится на сервере. И там будет нормальная, взрослая СУБД.

Суть в том, что имеющие SQL запросы (INSERT, JOINT LEFT - RIGT) делать на стороне клиента, и я задался вопросом себе, насколько это нужная задача, и какие аргументы мог бы противопоставить, что это нужно - не нужно?

Если вы хотите собирать текст запросов на клиенте, передавать на сервер, и там исполнять.
Не самый хороший вариант, но терпимо только в одном случае, если учетная запись пользователя в точности соответствует учетной записи в СУБД, и доступ к данным в СУБД четко ограничен правами доступа - из учетной записи в СУБД нельзя дотянуться ни до каких данных, не принадлежащих только этому пользователю.
Но такое редко бывает, так что воздержитесь от этой практики, воспользуйтесь лучше GraphQL/TreeQL, чтобы ограничить API только тем функционалом и теми данными, которые необходимы для конкретного пользователя.

Зависит от многих факторов:
1. Если это полноценное офлайн приложение:
- Если необходима полноценная СУБД (SQL Server, Postgres, MySql) - то нет. Мало кто захочет дополнительно себе устанавливать такие тяжелые зависимости, они всегда могут ее удалить и тогда уже не восстановить, обновления ПО либо не будут возможны, либо трудны
- Если это встраиваемая СУБД (SQLite) - то вполне да, так многие приложения делают (на андроиде слышал SQLite часто используют)
2. Если это онлайн приложение в браузере:
- localStorage - это key/value хранилище
- web sql - устаревшая технология
- куки - могут пропасть в любое время
3. Если это корпоративные клиенты, то можно навязать им свои требования по необходимости запуска СУБД на каждой машине

Тут все зависит от того, что под БД подразумевается и для каких целей это нужно

UPD: SQL запросы из клиента напрямую в БД - очень плохая идея, не надо так (обновления, безопасность, гибкость и т.д. - все постарадает)

DI, Dependecy Injection - это сам процесс внедрения зависимостей (например, когда ты зависимости через конструктор получаешь)
Пример:

class User
{
    IService _service;
    
    // DI
    User(IService service)
    {
          _service = service;
    }
}

DI-Container - это специальный контейнер, который может необходимую зависимость предоставить. Сначала ты в него регистрируешь все зависимости, а потом вызываешь метод по типу .getService("UserService") и он сам понимает какой сервис ты хочешь, какая у него реализация и как его создать (возможно для него нужны другие зависимости)
Пример

// DI-контейнер
var container = new DependencyContainer();
container.Register(typeof(IService), new ConcreteService());

var service = container.Get<IService>();

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

// Сервис-локатор
class ServiceRegistry
{
     IService Service;
     static IService GetService()
     {
           return Service;
     }
}

class User
{
     void DoSomething()
     {
           var service = ServiceRegistry.GetService();
           service.MakeStuff();
     }
}

Если файл лежит в папке со скриптом - надо открывать его, используя путь к пкапке со скриптом, а не надеяться на то, что текущий каталог совпадёт. Под виндой тоже всё зависит от способа запуска скрипта.
Так что читай про sys.argv[0] и модуль pathlib. Пригодится.

Убедитесь, что ваш сервер правильно отвечает на запросы OPTIONS. Добавьте OPTIONS в список Access-Control-Allow-Methods.
CORS Preflight