Сергей Соловьев

Ты используешь [Authorize] атрибут из фреймворка для авторизации, но при этом не следуешь правилам, чтобы фреймворк понял, что клиент авторизован. Как минимум - откуда он узнает, что токен для авторизации находится именно в куках с именем token?

В HttpContext есть метод SignInAsync. Этот токен нужно передавать туда, а не в куки. Дополнительно, нужно правильно настроить процесс авторизации.

Держи туториал по JWT авторизации

if (token is not null)
     {
         _httpClient.DefaultRequestHeaders.Add("Accept", "application/json");
         _httpClient.DefaultRequestHeaders.Add("Authorization", "Bearer " + token);
     }

- Этот код не имеет смысла, так как заголовок выставляется для созданного _httpClient, а не в запросе (дополнительно, Middleware - синглтон, а _httpClient у тебя один, он не может делать параллельные запросы)

Абсолютно каждое выражение в оборачивается в транзакцию. Даже одиночное.

Каждый раз вызывая execute ты создаешь новую транзакцию - ты сейчас делаешь не одну транзакцию, а 4. Вручную все оберни в BEGIN...COMMIT

Встроенные функции - это функции, которые доступны "из коробки". Это значит, что не надо их писать самим. По факту это такие же функции, как и самописные.

Если хочешь, то можешь создать функцию с таким же именем, что и встроенная. Тогда будет использоваться твоя.

Я делаю def min():
Что будет после двоеточия? Какая логика?

1. Создастся объект функции
2. Интерпретатор запишет этот объект в свое хранилище с ключом названия функции - если уже было, то перезатрет

Дальше будет использовать уже новый объект

1. Ссылаться нужно не на проект, а на другой пакет - тебе тогда надо публиковать 2 отдельных пакета

2. Изменить .csproj так, чтобы в пакете был нужный .dll

Создай на Панель управления ярлык и переименуй уже его

Ну я вроде и рассказал, что это противоречит тому же SOLID

Проектировать API надо по требованиям предметной области.

SOLID, REST и т.д. - это конечно же хорошо, но когда из-за них архитектура становится трудной к пониманию - тупое следование им только усугубит ситуацию.

а почему я не могу в API сделать метод DELETE и в него передавать и тип объекта, и его id

Почему нет? Если объекты создаются динамически, а не предопределены, то передавать их тип - хорошая идея.
Все зависит от проблемы.

Есть где кратко изложенная теория по этому поводу?

Вряд-ли. Все зависит от проблемы/предметной области.
Могу посоветовать алгоритм:
1. Выявить функциональные требования к системе
2. Представить их в виде условных функций
3. Переписать их в виде вызовов API (за основу можно взять готовые паттерны проектирования: REST, SOAP и т.д.)

Посмотрите на API VK или Telegram. Это не REST, но тоже удобно

Это вопрос не про ЯП, а про платформу./технологию ЯП здесь по факту ничего не решает.

Для мобилок либо под каждую конкретную платформу писать отдельно (отдельно для Android, для iOS и т.д.), либо использовать кроссплатформенные фреймворки (React Native. Xamarin и т.д.).

На счет сервера - совершенно без разницы, можно писать на любом языке/фреймворке. Здесь главное - что реализуется нужный интерфейс. Можете брать кого угодно.

Если Python, то надо брать больше оперативной памяти - 8 Гб минимум (хорошо если 16)
Процессор тоже важен, но не на столько как оперативка - любой Intel начиная с i3, либо любой AMD начиная с Ryzen 3.
Диск - SSD (не HDD, разница заметна), минимум 256 Гб (я был с 128 Гб, это ад).
Видеокарта будет не особо важна на данном этапе - можно брать любую.

Лично от меня совет - монитор матовый, IPS (глазам удобнее).
На клавиатуре пусть будет цифровой блок - больше комбинаций клавиш будет доступно (это цифры справа).
Для экономии - купите без предустановленной ОС, можно сэкономить много.

Попробуй через GET запрос и аргументы передавать в пути.

Вот тут пример

Обернуть каждую в другую таску, которая проглатывает все исключения.

try {
// Работа
} catch (Exception) {
// Пусто
}

Боты используют лонг-поллинг, поэтому DNS имя покупать/арендовать не надо, ровно как и платить за HTTP траффик приходящий (запросы). P.S. если ты на кол-беках делаешь, то надо.

В данном случае подойдет любой хостинг, который поддерживает контейнеры.
Такими могут служить:
- Яндекс.Облако
- Selectel
- Hostinger
- Digital Ocean

и т.д. Просто вбиваешь - хостинг докер контейнеров.

Если тебе нужно, хостить полноценное приложение (без докера), то круг выбора ссужается. Подсказать не могу.

Лично я пользовался яндекс облаком - разворачивал полноценный Backend-Frontend на докеркомпозе. При регистрации дают бесплатные деньги (около 3тыс.)

Предполагаю, что цикл (условие) должен быть здесь:
message.text == "Фрукты":

Сделай глобальную переменную, в которой будешь хранить последнее сообщение, а когда приходит новое сообщение делаешь проверку с этой переменной.

LAST_MESSAGE = None

@dp.message_handler(state='*', text=['Фрукты'])
async def fruits(message: types.Message, state:FSMContext):
    if message.text == LAST_MESSAGE:
            return
    # Логика
    LAST_MESSAGE = message.text

Зачем нужен Mutex? Есть ведь Monitor.

Mutex - примитив синхронизации уровня ОС.
Monitor - инструмент синхронизации уровня среды выполнения.

Mutex это разве не тот же семафор, только который может брать один поток?

Да, по внешним признакам. Но разве не лучше выделить специфичный кейс (как например в Mutex - одновременная работа только 1 потока) и оптимизировать работу для него, а не использовать везде обощенный инструмент (возможность для нескольких потоков в семафоре). Есть разные оптимизации для него.