Здравствуйте, binks, Вы писали:

B>Чтобы иметь id задачи необходимо хранить эти задачи и доставать для них результаты, RabbitMQ для этой роли не очень хорошо подходит и нужно использовать какое-то своё хранилище.
B>Я правильно понимаю, что нет такого инструмента два-в-одном?

В целом для реализации нужна:
— БД (для хранения статусов задач)
— брокер сообщений (для хранения и обработки задач)
— http app для выдачи состояния задачи наружу

Решения два-в-одном есть, например, celery (python, БД + брокер) + flower к нему (http api).

Здравствуйте, ·, Вы писали:

B>>Не текущая задач,
·>Т.е. ищешь серебрянную пулю?
Хочу определить рамки архитектурного решения.

B>>но, например, если в качестве сервиса будет корпоративная почтовая рассылка.
·>Что тогда будет ответом от такого сервиса? Который http клиент будет поллить в ожидании?
Статус отправки сообщения.

·>В этом конкретном случае тебе просто понадобится транзакционный сервис почтовых сообщений, а не искать "инструмент два-в-одном".
·>Впрочем, ты сказал "рассылка", тут вообще fire and forget. Не отправилось, так не отправилось, ну и реакции на невалидные емейлы, отписки, отправку в спам, етс. Т.е. это очень специализировання задача с соответствующим инструментарием.
В данном случае это рассылка, которая требует понимания того, отправилось ли сообщение

Здравствуйте, Kernan, Вы писали:

K>Здравствуйте, binks, Вы писали:

B>>Сервис1 говорит Сервису2 "дай информацию1". Сервис2 смотрет кэш, если данные отсутствуют, то делает дополнительную работу, если данных достаточно, то отдаёт результат.
K>Не похоже что тут вообще нужна шина.
В процессе обсуждения в этой теме именно такое понимание и пришло.

B>>Сам процесс уже реализован, но несколько неподходящим вариантом. Возникла потребность это исправить.
K>А каким вариантом?
К сути обсуждения это не имеет прямого отношения. Мне нужно вынести логику обработки из базы в отдельное приложение и я хотел понять уместно ли здесь использовать шину.

Здравствуйте, Буравчик, Вы писали:

Б>Решения два-в-одном есть, например, celery (python, БД + брокер) + flower к нему (http api).
Насколько я помню, celery тоже не решает задачи два-в-одном. Celery предоставляет обёртку для удобного использования из питона. Да и код у меня не на питоне.

Здравствуйте, binks, Вы писали:

B>Здравствуйте, Буравчик, Вы писали:

Б>>Решения два-в-одном есть, например, celery (python, БД + брокер) + flower к нему (http api).
B>Насколько я помню, celery тоже не решает задачи два-в-одном. Celery предоставляет обёртку для удобного использования из питона. Да и код у меня не на питоне.

Ну, я скорее подразумевал "готовое решение". А с питоном ты прогадал, да

Здравствуйте, binks, Вы писали:

B>>>Не текущая задач,
B>·>Т.е. ищешь серебрянную пулю?
B>Хочу определить рамки архитектурного решения.
Задача неясна.

B>·>Что тогда будет ответом от такого сервиса? Который http клиент будет поллить в ожидании?
B>Статус отправки сообщения.
Тоже всё очень условно..

B>·>В этом конкретном случае тебе просто понадобится транзакционный сервис почтовых сообщений, а не искать "инструмент два-в-одном".
B>·>Впрочем, ты сказал "рассылка", тут вообще fire and forget. Не отправилось, так не отправилось, ну и реакции на невалидные емейлы, отписки, отправку в спам, етс. Т.е. это очень специализировання задача с соответствующим инструментарием.
B>В данном случае это рассылка, которая требует понимания того, отправилось ли сообщение
Это же smtp. Под "Отправилось ли" можно понимать разные вещи. Если у тебя есть smtp сервер рядом, то это может означать, что сервер ответил "OK" о том, что он получил твоё мыло, что обычно занимает несколько миллисекунд, и вообще никакие очереди не нужны. А может означать, что он удачно отправил на сервер получателя, а это афаир может занимать до недели. И тут http-полл становится, мягко говоря, бессмысленным.