Если вы уже используете rmq и счастливы с ним - не надо пробовать bull) Это downgrade даже в плане стабильности

разбиваем монолит, например - банальные очереди на вебхуки. есть триггеры, на которые надо "отстукивать" по http клиентам, сейчас это вместе с выполнением триггера, нужно отдельно сделать. т.е. условно таска как раз на "попробовать что-то новое", гарантии bull устраивают, но очень много непонятных штук по поведению, плюс на офф репо (OptimalBits/bull) редирект на taskforcesh/bullmq.

вопрос - почему nest форсит bull и не дает альтернативы в доке по очередям, у микросервисов же есть rabbit и прочее

👍 а обертка при этом nestjsx/nestjs-amqp?

разбиваем монолит, например - банальные очереди на вебхуки. есть триггеры, на которые надо "отстукивать" по http клиентам, сейчас это вместе с выполнением триггера, нужно отдельно сделать. т.е. условно таска как раз на "попробовать что-то новое", гарантии bull устраивают, но очень много непонятных штук по поведению, плюс на офф репо (OptimalBits/bull) редирект на taskforcesh/bullmq.

вопрос - почему nest форсит bull и не дает альтернативы в доке по очередям, у микросервисов же есть rabbit и прочее

смотри rabbitmq - брокер сообщений
из плюсов
если один из консюмеров выходит из строя сообщение не потеряется
можно заюзать SSL
легкая кластеризация
удобный роутинг сообщений
транзакционность
но
rabbitmq сложнее администрировать

redis ( bull ) - очередь, а если очередь
то ты можешь отменить таску
запустить отложенно и что там еще в доке написано
прост в настройке
из минусов
так это может не держать большой нагрузки
роутинг не такой гибкий как у rabbitmq

спасибо! мы rabbit в основном используем как очередь) а bull очень манит порогом вхождения, буквально за вечер удалось бОльшую часть завести из того что хотели. по поводу потери сообщения - не уверен, но вроде бы сообщение не теряется и у bull при таком сценарии...

когда дойдет дело до отмены таски или отложенного запуска будет беда
и все эти плагины которые в инете есть, допустим, для отложенной отправки - это костыль
ибо для другого rabbit

да дошло уже) отложенная таска delayer, а отмена - не буду плохого рассказывать))))))

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

Добрый вечер.
Подскажите, пожалуйста.
Использую HttpService и отправляю пост запрос.
Примитив:

async create(createDto): Promise<CreatedDto> {
        const order = await this.createOrder(createDto);
        this.sendOrderInService(order)
            .subscribe(response => {
                order.status = true;
                order.save();
            });
        return new CreatedDto(order);
}

Нужно, чтобы только когда в сервисе создался заказ вернулся, ответ с Dto-ошкой. Как такое провернуть, чтоб не менять интерфейс метода (не изменять возвращаемый тип?
С Observable дел до этого не имел вообще.
Возможно очень туплю и достаточно добавить return new CreatedDto(order); в

subscribe

но он жеж вернет тот же Observable

или делать observable toPromise
или везде юзать Observable