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

Похоже на какие-нибудь циклические инклуды.
У вас в 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

например тот же ксамарин.

а вообще практика обычна - ядро пилится на одном, гуишки на нативе под платформу.

Под плюсы довольно много кросс-платформенных библиотек для GUI, самая известная, видимо, Qt.
Сам язык и его стандартная библиотека вполне кросс-платформенны. Но в разных компиляторах и в разных реализациях стандартной библиотеки могут быть свои нюансы.

Нет никаких "серверов OpenAPI", это обычный CDN, ну и ничего не мешает держать эти файлы у себя. https://fastapi.tiangolo.com/how-to/custom-docs-ui...

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

ну если ты с таким простым не справился, как ты хочешь доказывать что-то про "по безопасности и отправляемым данным"? Будешь отвечать, что тебе на этом сайте сказали, что документация безопасна или как?

Сейчас меня будут бить

Лично я бы посоветовал бы вас начать с C++. Сразу кажу, не из-за того что... Да чёрт его знает. В двух словах. Питон отличается от других языков программирования (Императивно - Декларативных), так что не очень хороший старт. Почему? Потому что у вас будет направление только Питон и, масимум Реакт. Я НЕ ГОВОРЮ ЧТО ЭТО ПЛОХОЙ СТЕК.

Для примера, почему я предлагаю начать с C++. Вы детально разберёте работу с памятью, типами данных, структурами и алгоритмами. Отсюда у вас буде уже очень мощная база для выхода куда угодно, та хоть в микроконтроллеры. Вообще отсюда можно идти уже во многих направлениях, C#, php, Java и т.д.

Но опять же, это моё субъективное мнение, что я считаю C++ лучше чем Python

UPD: да и C++ могли лучше прокачивает чем Python. На Python обычно очень много школьников начинают, на C++ работают инженеры)) Илон Маск начинал с программирования на C++ )))

Обработчиков у вас в любом случае 200 вешается.
Вся разница в том, что в первом случае они ссылаются на двести функций, а во втором на одну.
Создание функции требует определённых ресурсов, поэтому оверхед есть. Будет ли он заметным — это другой вопрос. Ответ на него зависит от того, что на самом деле в вашем коде происходит. На компьютере вы, скорее всего, разницы никогда не почувствуете, а вот на очень слабом телефоне при огромном количестве функций может начать тормозить.

P.S. Проще использовать делегирование в таких случаях.

setInterval