Вадим

Подключать приложение на React напрямую к базе данных - очень плохая идея. Код вашего сайта доступен для любого, кто откроет его в браузере. Соответственно, любые учётные данные, в данном случае от вашей базы данных, можно там же и подсмотреть. Выше верно написали: нужен бэкенд, например, на node.js, к нему будут отправляться API-запросы, например, через fetch или axios, и уже этот бэкенд будет связываться с базой данных.

Суть вопроса, как мне делать INSERT и SELECT запросы в вебсайте?

Никак. Эти запросы должен делать бэкенд.
А сайт должен делать http запросы к нему, например, при помощи функции fetch

При запуске ноды в переменной окружения LD_LIBRARY_PATH можете задать свои пути поиска библиотек.

LD_LIBRARY_PATH="тут_ваши_пути_поиска" node ./index.js

В том что если завтра вас уволят, то сможете отзываться на более широкий пул вакансий.
Ну и общий кругозор расширите конечно

Calculate не является асинхронной функцией поэтому async не нужен. И очень плохо вызывать в асинхронном коде Thread.Sleep, для асинхронного кода есть Task.Delay.

async преобразует код в конечный автомат (State Machine)

Если не хочешь после обучения оставаться голодным, то не изучай вордпрес...
Изучай фреймворки. Джунов берут за хорошие деньги со знанием одного из фреймворка laravel/symphony, с ВП либо фриланс, либо средненькая веб студия....

Во-первых, ардуино (ну как минимум китайские клоны) отдают определённый VID/PID USB устройства. Этим можно пользоваться для сужения диапазона поиска. Эту инфу можно узнать из реестра Windows.
Во-вторых, если ты контролируешь прошивку ардуинки, можешь заставить её отправлять какой-то хэндшейк (заранее известный пакет) при подключении к порту (обычно арудино перезагружается при коннекте к порту). Тогда достаточно подождать совсем чуть-чуть, отправка данных не потребуется. Также меньше шансов что-то поломать, отправив левые данные в неизвестное устройство.
В-третьих, просто сделай два последовательных цикла - один создаёт и запускает потоки, а второй их дожидается. Тогда ожидание будет параллельным.

Есть такой системный вызов select (а также подобные ему poll, epoll итд), суть которого - передать массив файловых дескрипторов (частный случай - сетевых соединений) и затем при получении событий ввода-вывода получить список тех дескрипторов, в которых произошёл ввод-вывод. Важно понимать, что при это программа "засыпает", передаёт управление ОС и не тратит ресурсов. ОС сама разбудит программу при наступлении нужных событий (записался файл, пришли новые сетевые байтики итд). Высокопроизводительные сетевые приложения (типа nginx, haproxy итд) используют подобный подход для того, чтобы эффективно обрабатывать большое количество сетевого трафика одновременно.

asyncio работает как раз примерно по тому же принципу. Когда случается ввод-вывод, нужная функция "засыпает", а управление передаётся потоку событий. Соответственно, он либо находит задачу, которая ожидает выполнения и передаёт ей управление, либо видит, что все задачи уже одидают какого-нибудь ввода-вывода и запускает select на все ожидающие дескрипторы (возможно, в реальности используется не select, а какой-то из его аналогов, но это для нас сейчас непринципиально). Как только приходит событие, программа просыпается, поток событий находит нужное событие и передаёт управление соответствующей задаче, которая его ожидала. Это позволяет очень эффективно в один поток работать с задачами, которые много ожидают ввода-вывода, но мало выполняют реальной процессорной работы.

Обычный ввод/вывод является блокирующим: пока не будет выполнена операция (чтение/запись/передача/приём), программа приостанавливает свою работу в ожидании. В asyncio весь ввод-вывод является неблокирующим: операции ввода-вывода не приостанавливают работу программы, а позволяют перейти к другим ожидающим задачам.

Обычный вызов sleep приводит к приостановке и засыпанию программы на указанное время (с передачей управления ОС), и в ней в это время ничего не выполняется. Как только время истечёт, ОС вернёт управление программе. Всё это время программа не работает, события ввода-вывода не обрабатывает.

В то же время asyncio.sleep возвращает управление потоку событий, а не ОС, что позволяет переключиться на выполнение других задач, обработать новые события итд итп. Программа не останавливается и управление ОС не передаёт (ну, кроме сна в процессе исполнения select), поэтому asyncio.sleep приводит к неблокирующему засыпанию, не мешающему выполнять задачи, которым ждать окончания сна одной конкретной задачи не нужно. Когда истечёт не менее чем указанное в asyncio.sleep время, поток событий вернёт управление приостановленной задаче.

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

Например, пусть есть функция, которая делает asyncio.sleep(1), затем три секунды работает числомолотилка без ввода-вывода. Тогда если у нас выполняются подряд с интервалами 0.1 с три таких функции, то первая задержит на 2.9 секунд возврат управления второй, а вторая - на 5.8 с третьей.

Это общий принцип, разумеется, там много нюансов и особенностей реализации.

Является ли нормальной практикой для девелопера создать ветку feature1 от не последнего коммита мастера, то бишь не от "g"

Да. В частности это стандартная практика разработчиков ядра linux: фичи должны расти от релизов или релиз-кандидатов, а не от каких-то случайных коммитов.

и потом смерджить feature1 с коммитом X2 затирая изменения f и g?

Из вопроса непонятно, это требование -- затирать, или это побочный эффект которого хочется избежать?
Если делать обычный git merge, то никакого затирания не будет. Будут конфликты, если изменения касаются одних и тех же мест, иначе будет объединение изменений ветки и мастера.
Чтобы затирать изменения можно делать git merge --strategy=ours -- в результате мёржа изменения сделанные в ветке которая мёржится будут потеряны.

Последний коммит в ветке сегодня, завтра уже может и не быть таковым.
Merge коммиты не "затирает" - пишите команды, которые используете.

В принципе все просто
- Создать зону api.company.com на втором DNS сервере
- На первом DNS cоздать NS записи для этого домена, в качестве хоста указать api, в качестве значения NS сервера второго хостера
Должно выглядеть примерно так

$ dig company.com NS
...
;; ANSWER SECTION:
company.com.		900	IN	NS	dns2.yandex.net.
company.com.		900	IN	NS	dns1.yandex.net.
...

$ dig api.company.com NS
...
;; ANSWER SECTION:
api.company.com.	3600	IN	NS	ns1.dns.npdc.ru.
api.company.com.	3600	IN	NS	ns2.dns.npdc.ru.
...

with t as(SELECT table_name, column_name, data_type, ROW_NUMBER() OVER (PARTITION BY table_name ORDER BY column_name) as num
  FROM information_schema.columns
  WHERE table_schema = 'public')
select json_agg(json_build_object(num, json_build_object(column_name, data_type))) from t group by table_name;