фреймворк, redis чтобы вебхуки хранить там и amqp для собственно общения с неким ядром.
У нас на http эндпоинт прилетает запрос, пишем в exchange и ждём ответ.
Я как реализовал сейчас: у меня прилетает ответ в очередь, срабатывает callback и мы порождаем системный процесс через использование asyncio.subprocess, по сути из консоли питонячий скрипт дёргаем и в аргументы передаём куда отправить и что отправить.
Какие ещё есть варианты и какие в теории минусы у текущего?
что и куда будет отправляться вебхуком?
стандартная модель работы вебхука, json отправляется на какой-то адрес который установил клиент
для отправки жсона я бы не стал плодить процесс
ну я могу этим процессом на самом деле сразу 10 сообщений отправить, в очереди может быть много сообщений
нужно держать контроль над общим числом процессов, а не порождать их бесконтрольно
ну как вариант можно тредпул сделать
ага, ну либо корутину
ну там же starlette. Просто не нравится мне идея, держать API, Клиент и Очередь в одном приложении
Варианты: 1. слать свой жсон "прямо на месте", из корутины; 2. selery
оба варианта не очень хорошие
Еще раз, нужно по какому-то событию слать куда-то жсон, так?
начнем с простого: отправляем жсон прямо из http хендлера. что не устраивает?
http хендлер получил запрос, отправил его в очередь и ответил
Обсуждают сегодня