И коннекторы к бд небось свои, да?

Твоя функция stateless

Ну вот "http request" - это же не фласковый реквест, не саник

Ну да. Но мне же надо куда-то данные сохранять

Да. Свое. Но тебе там вряд ли понадобится что-то большее, чем request.get_json()

Общаться с базами по сети. Я это уже не пробовал. У меня боты stateless.

Ну и с обычной базой я по сети общаюсь.

По http*

Общаться с базами по сети. Я это уже не пробовал. У меня боты stateless.

Понятно что по сети. А где взять нужные зависимости? Там же наверняка только встроенные коннекторы для своих же сервисов

А транзакции?

Ну да. Но мне же надо куда-то данные сохранять

Ну как, повесить один middleware на все десять функций апи. Или ещё что

Ну вешай. У тебя одна входная функция. Из нее сам подключай мидлвари и раскидывай реквесты по подфункциям.

Ну и с обычной базой я по сети общаюсь.

А транзакции?

А что мешает транзакции в http делать в рамках сессии?)

А что мешает транзакции в http делать в рамках сессии?)

Ну, в реальности транзакции же находятся в самой бд. Достаточно просто сначала делать условный login и получать идентификатор сессии, с которым дальше ходить в бд. И транзакции не будут проблемой, как мне кажется. В копилку к этому есть websocket или keep-alive штуки

Ну, в рамках http можно сделать так: 1. login -> получен токен 2. выполняешь запрос c условным {'session': 'token', 'query': 'BEGIN TRANSACTION'} 3. выполняешь запрос c условным {'session': 'token', 'query': 'UPDATE required'} 4. выполняешь запрос c условным {'session': 'token', 'query': 'UPDATE another'} 5. выполняешь запрос c условным {'session': 'token', 'query': 'COMMIT'}

В редис. =)

И куда же я буду данные класть между запросами?

Результаты запросов тебе приходят в ответе на запрос

В плане? Запросы же выполняются в бд

На самом деле я не знаю, как разруливают продвинутые кейсы в такой архитектуре. Но как-то разруливают.

Ну я буду в БД открывать транзакцию и ждать повторных запросов? Никаких гарантий что следующий запрос по http прилетит в тот же инстанс сервеоа

Обычно в такой схеме запросы просто роутятся внутри кластера

Невозможно - у вас есть какие-то физические ограничения, которые это запрещают?

Вы же понимаете, что можно не привязать транзакцию к коннекту?

То есть, если запрос приходит на сессию, которая была заведена в другом прокси, запрос перенаправлялся туда

Почему-то pip install pygame выдаёт ошибку

Гарантировать что два хттп запроса придут на один сервер - невозможно

попробуйте сменить прокладку между стулом и монитором.

sticky session