Кого куда коммитить в symfony/messenger?

Question

[grabbee]

Симфони есть компонент работы с очередями. Там нужно сделать объект Message и отправлять его в очередь. А оттуда её заберет обработчик. Получается Класс объекта Message должен быть одновременно на обоих концах "очереди".

Но а если это два разных сервиса и они коммитятся в разные репозитории. Это одновременно коммиты делать в оба сервиса? Или мудрить что-то на подобие Симфони Contracts?

Comments

[Daria Motorina]

Надо консьюмер описать в том втором репозитории, главное корректно принять этот месседж. А что такое Symfony Contracts?

[grabbee]

Так чтобы его принять, в Symfony нужен объект этого Message (сериализуемый класс). Он одинаковый и при отправке и при получении. И должен быть с обоих сторон. И если я захочу что-то в него добавить, то нужно будет дублировать изменения на стороне обработчика. Я конечно и так там буду что-то писать. Но например будет Третий сервис который захочет послать сообщение. И в него тоже этот класс переть. И при обновлении коммитить изменения во все эти сервисы.

https://symfony.com/doc/current/components/contrac... - они всё общее выделили в отдельные репы и назвали их Контрактами. Я тоже сейчас попробовал так, и объекты сообщений туда запихнул. Теперь нужно будет делать composer update на всех сервисах вместо ручных правок этих классов. Не уверен что это правильно... Но пока красиво

[BoShurik]

grabbee, https://github.com/symfony/symfony/issues/33912

[grabbee]

Зелененько ещё... Актуальненько :)

[grabbee]

BoShurik, хотя они немного о другом. Сериалайзер кажется пихает неймспейс в Message - и когда он отличается на обработчике, он не может его принять. Я немного о другом. О том что в принципе нужно класс дублировать на все сервисы которые используют эту очередь. Например у вас 1000 сервисов. И вы решили добавить в это сообщение какой-нибудь ID - вам придется во все 999 лезть, чтобы изменить Message, и 1 на обработчике.

[BoShurik]

grabbee, они там обо всех вариант: и что на принимающей стороне не php вообще, и что класса такого может не быть.

Можно попробовать https://github.com/Happyr/message-serializer - обычный json_encode с метаданными

[BoShurik]

grabbee, ну если вы добавляете поле id, то проблема не сколько в отсутствии поля в сообщении, сколько в том, что это поле не будет обрабатываться всеми 1000 сервисами, пока вы их не обновите

[grabbee]

Вам нужно в голове держать все сервисы которые шлют этот Message в очередь. И не забыть обновить его, иначе их перестанет обслуживать обработчик. А если каждый ту-пицца сервис имеет своего разработчика, так это ещё каждому объяснить, где и что изменить....

[grabbee]

BoShurik, сервисы посылают же. Им всё равно. Это обработчик может 500 словить например, когда null получит.

[BoShurik]

grabbee, это уже не проблема symfony/messenger, а в целом обратной совместимости публичного API

[grabbee]

BoShurik, пробежал по тексту, не вчитывался. Попробую более углубиться сейчас.

[grabbee]

не будет обрабатываться всеми 1000 сервисами, пока вы их не обновите

Я же говорю. Хорошо если всё одному патчить. А если это разные команды. Кто-то в отпуске и тд. Я сейчас пробую модель с контрактами. Кажется ведь проще update запустить чем лезть в код каждого сервиса. Я через месяца два уже забываю где что написано...

[BoShurik]

grabbee, нет, тут вопрос проектирования. Представьте, что у вас API и 100500 клиентов с мобильными приложениями. Как вы заставите их всех разом обновится? При разработки вашего API надо сохранять обратную совместимость. Так и в вашем сервисе. Надо чтоб работали старые и новые Message.

Я так понимаю у вас что-то вроде сервиса отправки, к примеру, SMS и клиенты, которые этим пользуются? Я бы выделил еще отдельный пакет, который бы использовался как клиент к вашему сервису. Т.е. не просто Message туда запихнуть, а прям всю работу по отправке сообщения, где под капотом бы уже использовался symfony/messenger

[BoShurik]

grabbee, мы так или иначе об одном и том же :) Идея в том, чтобы оно работало и без update (в разумных пределах, само собой)