У меня есть задача - вынести огромный кусок логики и кода в пакет для переиспользования.
Но для тестирования и работы этого кода требуется настройка symfony\messenger.
Изначально вся логика кода была написана и опробована внутри symfony и работало все хорошо.
Но вот при попытке настроить подобную же среду в пакете для тестирования кода я столкнулся с проблемой.
Очень сложно настроить пакет symfony\messenger вне symfony.
есть небольшие инструкции про синхронную очередь и на этом все.
А мне требуется 1 синхронная и 2 асинхронные.
На хабре даже статью находил, но там все примитивно, чего не достаточно для меня.
Задача настройки взаимодействия 3 очередей вне симфони оказалась очень сложным делом.
Может у кого то есть опыт или ссылка нормальную инструкцию как это сделать?
Так же столкнулся с проблемой, что требуется DI для этого.
И вот он выдается что есть циклические зависимости, когда 1 хендлер обрабатывает сообщение из очереди и отправляет ее в другую синхронную или асинхронную.
С этого и начал.
Вся штука в том, что там описан простейший способ настройки синхронной шины.
А вот если начать комбинировать шины, то начинается засада.
dinya17, сейчас ваш вопрос выглядит максимально абстрактно. Попробуйте конкретизировать. В идеале проект на гитхаб выложите, тогда можно будет что-то конкретное посоветовать
dinya17, засада с какими войсками?
Что значит "синхронная/асинхронная шина"? Симфони шину не предоставляет, он предоставляет инструмент посыла сообщений и их прослушивания.
хмм, 3 шины.
1 работает через синхронный транспорт
2 работает через асинхронный транспорт
3 работает через асинхронный транспорт
Задача такая.
Отправлять сообщения в одну шину AsyncBusA , работающую через асинхронный транспорт.
Это сообщение получается в AsyncBusA в этой шине через шину в синхронном режиме выполняем сообщение какое - то.
Теперь надо отправить изAsyncBusA сообщение в AsyncBusB
В AsyncBusВ мы получаем сообщение что - то вычисляем для себя и снова отправляем сообщение в AsyncBusА.
BoShurik, я выше привел конфиг. В нем мой код и там же написано ContainerInterface $container
Это и есть DI.
Вот где я его использую, там он требуется, сам Mesenger требует DI.
Без него не могу запустить, а с ним получается циклическая зависимость.
dinya17, это же не значит, что надо все конфигурировать через DI. Варианты навскидку:
- имплементировать свой SendersLocatorInterface без использования контейнера
- имплементировать свой ContainerInterface
- взять