Юра
Каждый уровень абстракции вносит сложность. Поэтому просто каждый раз надо взвешивать плюсы и минусы
Юра
Тут нет какого-то универсального правила
Юра
Помним про KISS
Павел
Ну так по логике. Все что асинхронно, почему бы и не мессенджер?
Не, вопрос в том, создавать ли еще 2 дополнительных класса.
Пилот
Вопросик про абстракции, раз уж пошла пьянка.
Абстрагируетесь ли от мессенджера?
Ну вот доспусти есть комманд/хандлер. Можно юзануть из контроллера. Задача: юзануть асинхронно.
Вижу два варика:
1) Добавить интерфейсы/атрибуты к текущим классам.
2) Сделать некие мессадж/мессаджХэндлер поверх и уже к ним навешать из п1.
У меня абстракция это интерфейс в апликейшн слое по которому по di прогружается реализация из инфры. Юзаю симыони месенлжер
Пилот
Правда я шину юзаю ток в апликейшн (
Null
Ну опять же. Насколько все обстрактно.
Вот есть типа "сообщение об успешной регистрации".
Это может быть смс. Может быть письмо. Может быть почтовый голубь. Зачем сервисы регистрации знать, чем именно сообщение?
Null
Он мессенджеру сказал - ДЕЛОЙ. А тот разберется уже.
Павел
Не, немного не о том.
Юра
Ну и пусть они все налседуют от саксес регистрейшн меседж
Юра
И не надо знать от какого конкретно
Null
Я обычно мессенджер юзаю все-таки на асинках.
То, что можно сделать не сейчас, а потом.
Пилот
Я обычно мессенджер юзаю все-таки на асинках.
То, что можно сделать не сейчас, а потом.
У меня кстати инфра шины дёргает симыонийский ивент диспачер для НЕасинков, а для асинков дёргает бас месенджера
Павел
Есть комманда "CreateUserCommand", Есть Хэндлер "CreateUserHandler" (на нейминг не смотрите.). Вот мы их юзаем в контроллере.
Пришла задача - юзануть асинхронно.
Два варианта:
1) в CreateUserCommand добавляем необходимые интерфейсы/атрибуты, и делаем $bus->dispatch(new CreateUserCommand());
2) Делаем CreateUserMessage и CreateUserMessageHandler. Делаем bus->dispatch(new CreateUserMessage()); ,внутри CreateUserMessageHandler отлавливаем мессендежером CreateUserMessage преобразуем в CreateUserCommand и вызываем CreateUserHandler. Т.е. не смешиваем CreateUserCommand с асинхронностью.
Юра
Не знаю я вообще не так делаю
Пилот
У меня кстати инфра шины дёргает симыонийский ивент диспачер для НЕасинков, а для асинков дёргает бас месенджера
<?php
declare(strict_types=1);
namespace App\Shared\Infrastructure;
use App\Shared\Application\MessageBus as MessageBusInterface;
use Symfony\Component\Messenger\MessageBusInterface as MessageBusImplementation;
use Symfony\Contracts\EventDispatcher\EventDispatcherInterface;
final class MessageBus implements MessageBusInterface
{
private MessageBusImplementation $messageBus;
private EventDispatcherInterface $dispatcher;
public function __construct(MessageBusImplementation $messageBus, EventDispatcherInterface $dispatcher)
{
$this->messageBus = $messageBus;
$this->dispatcher = $dispatcher;
}
public function dispatch(object $event)
{
$this->dispatcher->dispatch($event);
$this->messageBus->dispatch($event);
}
}
Юра
Я юзаю свой сервис для обработки задач, месенджер чисто для асинк задач
Павел
CreateUserHandler и есть "свой сервис"
Юра
В клиентском коде я не создаю меседжи месеенджера
Павел
В клиентском коде я не создаю меседжи месеенджера
Ну т.е. у вас есть некий UserManager, а потом если надо 1 задачу из него пульнуть в месседжер, вы делаете мессадж и хандлер. Когда "менеджеры" немного попроще с этим.
Павел
А тут есть варик не делать эти мессаджи и хэндлеры, но выходит завязано немного на мессенджере самом
Юра
а чо так?
Потому что всеравно обычно нужно реализации полноценной пайплайн с отслеживанием статусов, зависимыми задачами, опциональными тасками и т.д. и все это сделать месенджером не очень тривиально
Юра
Поэтому мессенджер у меня чисто транспорт для асинк тасок
Юра
Так сказать разделение ответственности
The Ant
а как же ивенты?
асинк ивенты
Юра
Что за ивенты
Юра
Конкретнее можно?
The Ant
ну вот создал ты юзера, и надо бросить ивент что юзер создан. Чтобы все, кому нужна эта инфа сделали что-то с ней.
The Ant
далеко не все штуки можно и нужно делать прям там, где ты создал юзера
Юра
Не у меня пайплайн заранее создан. Если нужно как ты сказал, я кину обычный ивент в ивент бас, подписчик сделает свой пайплайн и отправит его на выполнение
Юра
Либо через пацплайн билдер изменю готовый
The Ant
т.е. через 2 ивента только задача будет выполнена? не совсем понимаю в чем профит такого мува
Юра
Много профитов
The Ant
ивенты сами по себе сложно воспринимая штука для человека. Постоянно с ними проебываешься. А тут аж два штуки друг за другом
Юра
Когда ты имеешь дерево задач, ты четко понимаешь что есть что, можно сдампить дерево для дебага, делать зависимости и т.д. Для моих задач мессенджер слишком низкоуровневый
The Ant
я в джсе такое делал, было больно 😄
Юра
Если все задачи в дереве не асихронные, они просто сразу выполняться все рекурсивно и всё
The Ant
надо нверное название придумать для такого. Как насчет Proxy events? 😄
Юра
У меня чет слово прокси ассоциируется с каким-то гемором и багами)
Юра
Хм столкнулся с непонятным поведением
Юра
Короче есть энтити с полем типа json. Оно мапится в JSON тип в БД. В бд оно по дефолту null.
Когда сериалайзер нормализирует эту энтити, он игнорит это поле вообще.
Юра
у меня стоит
AbstractObjectNormalizer::SKIP_NULL_VALUES => false,
Юра
но дело в том что оно почему-то остается uninitialized а не нул
Юра
наверное надо его сделать нулабл, может в этом беда
Юра
просто раньше поле типа json по дефолту становилось []
Юра
а сейчас null
Юра
Это в коде
Юра
А существующие записи по дефолту null становятся
Юра
А ставишь дефолт, пишет поле типа json не может иметь default value
Юра
Еще из серии замечательных вопроов: когда не нужно комитить composer.lock файл?
Юра
Мне вот интересно что с фантазией у авторов этих вопросов
Dmitriy
Сергей
Еще из серии замечательных вопроов: когда не нужно комитить composer.lock файл?
когда библиотеку разрабатываешь)
Юра
У меня вопрос а как вообще лок файл появился в библиотеке?
Сергей
мейнтенер закоммитил)
Юра
Я вот пишу бандлы и у меня нет там никаких лок файлов
Юра
Да и ок а что будет если знакомить лок файл у библиотеки? Композер при установке этой либы просто его проигнорируеь
Сергей
ну а смысл его коммитить? зачем тебе фиксировать версии?
Юра
Так нет смысла его создавать даже )
Юра
Зачем комитить то чего нет
Юра
Я обычно создаю рут проект, в который подключаю либу через локальный репозиторий, и автоатом подтягиваются её зависимости. В такой ситуации нет никакого лок файла. Но если делать неправильно то конечно он будет. Т.е. вопрос из серии делай нормально и не будет этого вопроса )
Сергей
ты уверен, что ты делаешь правильно?
Юра
А что не так?
Сергей
то есть у тебя нет папки vendor в проекте с библиотекой?
Юра
На наверное давнг не писал чисто либы. Нет. У меня бандлы и в них нет вендор папки
Юра
Ок развиваем дальше мысль. Ты зависишь от тестов. Значит зависимость пойдет в require dev. Почему ч не могу закомитить лок файл со своими дев зависимостями?
Юра
Например мне важно чтобы когда я пересяду за другой ноут, я поставил дев зависимости в тех версиях которые я юзал
Юра
Или тиммейт чтобы работал с теми же версиями дев зависимостей либы
Сергей
мы говорим про какую то либу для своей команды или нормальный open source?
Юра
Да про любую
Gleb
Пробежался по бандлам - нигде нет lock файла,
Пробежался по composer.json - где надо в нём лочат конкретные версии. Но большинство зависимостей с широкой вариацией по версиям.
Юра
у меня тоже нет в бандлах лока файла в принципе
Юра
потому что нет никакого смысла в этом