Никакого похожего принципа.
fetch - часть браузерного API, которое позволяет отправлять http запросы. Так случилось, что функция возвращает Promise, хотя могла бы и в callback возвращать данные, кидать событие или вообще работать синхронно.
Promise - это нечто другое, и к fetch отношения имеет мало
1. Через обменник можно раскидать одно сообщение на много очередей - либо используя fanout тип обменника - тогда сообщение попадет во все очереди одновременно, либо по шаблону routing key (тип - topic) - тогда сообщение попадет во все очереди, где шаблон подписки (routing key) соответствует routing key сообщения. Direct обменник - сообщение попадет только в ту очередь, название которой соответствует routing key.
2. На картинке как раз показано, что одна очередь привязана к обменнику 2 раза по разным routing key
3. ИМХО, если пропускная способность не важна - рекомендую взять сразу topic - он может работать как fanout и direct в зависимости от настройки подписки.
Отправляю в очередь сообщения. Консьюмеров нет.
Включаю консьюмера, он не видит старые сообщения, и получает только новые.
А есть ли очередь? И сообщение точно отправилось? Даже если нет обработчиков, все-равно сообщения в очереди должны накапливаться...
Если отправить сообщение в обменник и он не будет знать куда деть это сообщение (не привязано никакой очереди) то сообщение пропадет.
Обменник не может накапливать сообщения.
Abcdefgk, var не 100 долларов что бы нравится. Но у него есть ряд особенностей, которые надо помнить всегда. При использовании let/const их можно не помнить. Просто странно - использовать import вместо require (ИМХО существенной пользы оно не приносит) но не использовать let/const, async/await и т. д. - то, что реально приносит пользу.
наверняка из-за этого -
или из-за того что это должно быть поднято у меня локально.
Видимо вот это:
не сработало.
Я по SOAP не особо, так что на этом все :-)