Комментарии 5
Здравствуйте, спасибо за ваш труд.
Хотелось бы чтобы также раскрыли нюансы как строить апи и при этом происходила работа со стрима и/очередями. Как и в какой момент возвращается сообщение по окончании, стоит ли это делать в том же обработчике или это хорошо выглядит цепочкой вызывов/сообщений.
Спасибо за обратную связь!
К примеру, хотим сделать какую-то cpu bound задачу - нагрузить сервис, подождать результат. Сгенерировать картинку, к примеру. Или обработать что-то по таким-то опциям. Скинул опции/промт, ждёшь результата. Как можно получить ответ?
Дальше пошла классика System Design :)
long polling - не закрываем TCP соединение. Периодически опрашиваем
websocket - двусторонняя связь - откроем дополнительное соединение, по которому ожидаем прихода события
Просто каждый раз прожимает кнопку "Узнать статус". Открывается соединение, реализуется запрос с ответом готово/ещё нет, закрывается соединение.
У каждого подхода есть свои +-.
Какой api сделать:
POST /make_cpu_bound_task/ body - {info} - для отправления задачи.
GET /status/{task_id}
Окей, спасибо
а что-то менее тривиальное, к примеру у нас пул воркеров но задачи отстреливают очень быстро и нет смысла закрывать соединение чтобы поллить, как хендлеру взаимодейстовать с этим пулом на примере очередей? Для примера - мы погрузили пейлод в некий sqs, дальше лямбды сделали дело и как вернуть результат работы в том же запросе?
К примеру, возьмём flask. Его можно запустить в многопроцессорном режиме с распределением запросов. И, всё-же, внутри в коде, всё сведется к одной функции/обработчику/handler'у этого endpoint'а.
Если мы идём от того, что хочется задачи отстреливать очень быстро и нет смысла закрывать соединение тогда, возможно, нет смысла использовать очередь.
Тогда мы возвращаемся к синхронным вызовам внутри функции. Просто вызовем внутри синхронно другую функцию - специфичный обработчик - дождёмся выполнения, вернём результат обработчику, сформируем ответ, ответим в этом же соединение.
Если же подразумевается, что, всё-таки, у нас отдельный сервис для выполнения этой таски - в сообщение указаны лямбды - то мы также делаем запрос в их сторону/вызываем их api синхронно, ожидаем ответа. Т.е. это уже второй вариант - посчитали что-то, но другими средствами, в другом сервисе. Но идейно всё теже блокирующие вызовы внутри обработчика. Пока живёт соединение.
Можно поискать информацию про устройства flask. Он удобен для обслуживания api. Но не даёт возможности заглянуть внутрь. Возможно, наткнётесь на мой вопрос на reddit, где я пытался достучаться до распределителя запросов. В целом/в среднем в этом фреймворке или же в вашем, очень может быть что вглубь вам доступа не дадут.
Как и не дадут возможность по ручному управлению TCP соединениями. Т.е. у вас пул таких соединений, которые инициировал клиент своими запросами. С другой стороны у вас пул выполненных задач. И вы не можете вот так напрямую выполнить метод типа connection = get_free_connection(); connection.send_response(calculated_task)
Вы как пользователь фреймворка находитесь на верхнем уровне абстракции - в синхронных обработчиках. А где-то под капотом пока что живёт tcp соединение, чтобы фреймворк дойдя до return взял Ваш результат и послал по этому соединению ответ. Но это уже не в Вашей области деятельности. На то он и фреймворк, чтобы оградить его пользователя от низкоуровневой специфики.
Вам же захотелось туда доступа. Тогда добро пожаловать в клуб С++/rust/C разработчиков :)
Надеюсь, ответил на вопрос)
Хм, у меня в целом были похожие мысли, хотелось чтобы кто-то подтвердил :)
Помню как-то в доках для sqs находил примеры на джаве, где создавали эфемерную (временную очередь) в соседний сервис, отправляли имя как один из параметров в основную очередь и ждали ответа с таймаутом. Выглядит конечно необычно, но сознание расширяет
System Design для начинающих: всё, что вам нужно. Часть 4