Симфони есть компонент работы с очередями. Там нужно сделать объект Message и отправлять его в очередь. А оттуда её заберет обработчик. Получается Класс объекта Message должен быть одновременно на обоих концах "очереди".
Но а если это два разных сервиса и они коммитятся в разные репозитории. Это одновременно коммиты делать в оба сервиса? Или мудрить что-то на подобие Симфони Contracts?
Так чтобы его принять, в Symfony нужен объект этого Message (сериализуемый класс). Он одинаковый и при отправке и при получении. И должен быть с обоих сторон. И если я захочу что-то в него добавить, то нужно будет дублировать изменения на стороне обработчика. Я конечно и так там буду что-то писать. Но например будет Третий сервис который захочет послать сообщение. И в него тоже этот класс переть. И при обновлении коммитить изменения во все эти сервисы.
https://symfony.com/doc/current/components/contrac... - они всё общее выделили в отдельные репы и назвали их Контрактами. Я тоже сейчас попробовал так, и объекты сообщений туда запихнул. Теперь нужно будет делать composer update на всех сервисах вместо ручных правок этих классов. Не уверен что это правильно... Но пока красиво
BoShurik, хотя они немного о другом. Сериалайзер кажется пихает неймспейс в Message - и когда он отличается на обработчике, он не может его принять. Я немного о другом. О том что в принципе нужно класс дублировать на все сервисы которые используют эту очередь. Например у вас 1000 сервисов. И вы решили добавить в это сообщение какой-нибудь ID - вам придется во все 999 лезть, чтобы изменить Message, и 1 на обработчике.
grabbee, ну если вы добавляете поле id, то проблема не сколько в отсутствии поля в сообщении, сколько в том, что это поле не будет обрабатываться всеми 1000 сервисами, пока вы их не обновите
Вам нужно в голове держать все сервисы которые шлют этот Message в очередь. И не забыть обновить его, иначе их перестанет обслуживать обработчик. А если каждый ту-пицца сервис имеет своего разработчика, так это ещё каждому объяснить, где и что изменить....
не будет обрабатываться всеми 1000 сервисами, пока вы их не обновите
Я же говорю. Хорошо если всё одному патчить. А если это разные команды. Кто-то в отпуске и тд. Я сейчас пробую модель с контрактами. Кажется ведь проще update запустить чем лезть в код каждого сервиса. Я через месяца два уже забываю где что написано...
grabbee, нет, тут вопрос проектирования. Представьте, что у вас API и 100500 клиентов с мобильными приложениями. Как вы заставите их всех разом обновится? При разработки вашего API надо сохранять обратную совместимость. Так и в вашем сервисе. Надо чтоб работали старые и новые Message.
Я так понимаю у вас что-то вроде сервиса отправки, к примеру, SMS и клиенты, которые этим пользуются? Я бы выделил еще отдельный пакет, который бы использовался как клиент к вашему сервису. Т.е. не просто Message туда запихнуть, а прям всю работу по отправке сообщения, где под капотом бы уже использовался symfony/messenger
