Иван
как это не сервис статей знает кто автор
Павел
как это не сервис статей знает кто автор
Где нам нужен автор? В какой части логики? Надо исходить из этого.
Иван
в части отображения для подтаскивания имени автора и ссылки на страницу всех статей автора
Иван
или у тебя отдельный сервис авторства?
Михаил
В том то и прикол что нам технически нужен только id а уже сам фронт может запросить отдельно имя и почту автора к примеру
Павел
в части отображения для подтаскивания имени автора и ссылки на страницу всех статей автора
Отображение вообще может быть отдельным ридом, который соберет со всех сервисов данные
Павел
Поэтому рид не трогаем
Михаил
или cBFF который скомпонирует 2 запроса
Павел
Опять же я не топлю за этот вариант, а просто говорю что он есть. И он неплохо вкладывается именно в то, что сервис должен быть самодостаточный.
Если сервис авторизации знает кто автор (хозяин или дубликатор), ему не нужно будет ходить в сервис статей за этим. Если мы рассматриваем какой то самодостаточный авторизатор
Михаил
Но при этом если мы рассматриваем сервис доставки сообщений пользователю - он должен знать email телефон телеграм итд итп пользователя - потому что это его домен\
Михаил
Тут больше нужно применять паттерн "информационный эксперт"
Ну и не бояться задублить данные - это ок
Павел
Опять же я не топлю за этот вариант, а просто говорю что он есть. И он неплохо вкладывается именно в то, что сервис должен быть самодостаточный.
Если сервис авторизации знает кто автор (хозяин или дубликатор), ему не нужно будет ходить в сервис статей за этим. Если мы рассматриваем какой то самодостаточный авторизатор
Либо авторизация будет на нескольких сервисах - гейтвей проверяет роль, а сервис статей - автора
Павел
Ну еще главное на реальных проектах не мудрить больше нужного))) на петах да, можно и поизголяться
Михаил
Да - давайте всё фигачить монолитами
Павел
Да - давайте всё фигачить монолитами
Ну это лучше чем фигачить все микросервисами так где они не нужны.
Михаил
А кто-то так делает?
Павел
А кто-то так делает?
Возможно многие. Микросервис должен решать какие то проблемы, которые покрывают те проблемы который он принесет.
Даже если он есть, не факт что он нужен.
Сделать микросервис != что то решить и правильно это организовать.
Даже автор читает книгу по ДДД, но почему то перенес идею именно в микро, потом захочет это испробовать на проде.
Микросервисы - это риски, дополнительные накладки, банальное сетевые
Михаил
Кто ему это даст? Или он единственный программист на работе?
Павел
Кто ему это даст? Или он единственный программист на работе?
Что у нас мало работ, где 1-2 прогера в команде бэка?
Михаил
Ладно, уже глупый флейм пошёл
Михаил
(с моей стороны)
Михаил
Буду признателен если покажете, что такое тип сообщения в рамках кролика
Кстати, ты спрашивал про это.
Разве логика в кролике и в кафке не похожая. Одна очередь - один тип сообщений.
Допустим очередь user-queue, там сообщения типа:
{"type":"update","user_id":"1488","payload":{},"timestamp":322}
{"type":"delete","user_id":"1488","timestamp":420}
Ну или конкретная очередь user-deletion-queue
{"user_id":"1488","timestamp":420}
Я понимаю что можно всё пихать в одну очередь. Но так можно поступить с любой технологией. Использовать бд как распределённый лог, а кафку как кеш
Vlad
Ну это лучше чем фигачить все микросервисами так где они не нужны.
С микросервисами куча бед/неудобств, а сколько саппорта нужно в плане инфры
Павел
Кстати, ты спрашивал про это.
Разве логика в кролике и в кафке не похожая. Одна очередь - один тип сообщений.
Допустим очередь user-queue, там сообщения типа:
{"type":"update","user_id":"1488","payload":{},"timestamp":322}
{"type":"delete","user_id":"1488","timestamp":420}
Ну или конкретная очередь user-deletion-queue
{"user_id":"1488","timestamp":420}
Я понимаю что можно всё пихать в одну очередь. Но так можно поступить с любой технологией. Использовать бд как распределённый лог, а кафку как кеш
Ну смысл тут в том, что тип - это внутрення логика приложения. Т.е. вы засунулу какой стринг, в котором какой то json в котором какой то ключ type.
С точки зрения брокера - он этого не понимает
Михаил
А должен
Михаил
это инструмент
Павел
Кстати, ты спрашивал про это.
Разве логика в кролике и в кафке не похожая. Одна очередь - один тип сообщений.
Допустим очередь user-queue, там сообщения типа:
{"type":"update","user_id":"1488","payload":{},"timestamp":322}
{"type":"delete","user_id":"1488","timestamp":420}
Ну или конкретная очередь user-deletion-queue
{"user_id":"1488","timestamp":420}
Я понимаю что можно всё пихать в одну очередь. Но так можно поступить с любой технологией. Использовать бд как распределённый лог, а кафку как кеш
Опять же многие пихают, особенно только начинающие с мессенджером всё в async транспорт,весь свой апп
Павел
И все это нормально работает,в целом без проблем
Михаил
Это интрумент для передачи сообщений, логирования. Он свое выполняет
Имхо - сувать разнотиповые сообщения в одну очередь, это превращать кролик в мусорку.
Всё равно что хранить всю бд в одной таблице. Не ну а чо...
Михаил
Я хочу подписаться только на удаления пользаков - но должен вычитывать тонну того, чего мне не нужно
И что делать, накать?
Павел
Там только такие проблемы:
- невозможное скалировани конкретной задачи
- скорость обработки (но решает консюмерами)
- непонятно что сломалось или тормозит
Павел
Я хочу подписаться только на удаления пользаков - но должен вычитывать тонну того, чего мне не нужно
И что делать, накать?
Вы просто ждете своего сообщения, т.е. обрабатывюатся все
Павел
Если у вас rps в очереди 1 сообщение в сек, вообще проблем нет сколько там типов
Павел
Все будет обрабаьываться быстро
Павел
user_update, payment_create, user_delete, user_create
Забираются все по очереди, все обрабатываются.
Павел
Просто консюмер матчит обработчики (случай с мессенджером)
Павел
А не сам консюмер - это обработчик конкретного сообщения
Павел
Т.е. как роутинг, есть index.php который принимает всё, а потом матчит по контроллерам
Павел
Или больше консюмеров туда пихаете
Михаил
если разные очереди мне нужно с разной скоростью читать. Или разный приоритет
Павел
Михаил
Блин это как яд всех ORM - когда объекты управляют структурой бд. Вы берёте симфони мессенджер и он почему-то начинает управлять очередями в кролике
Павел
если разные очереди мне нужно с разной скоростью читать. Или разный приоритет
Вы просто накидываете, то нельзя и что проблемнее. Да с этим проблема есть, но когда есть РПС высокий и нагрузка
Павел
Блин это как яд всех ORM - когда объекты управляют структурой бд. Вы берёте симфони мессенджер и он почему-то начинает управлять очередями в кролике
Он ничем сам не управляет, всё настраивается
Павел
Честно я не понимаю, чем мессенджер отличается от чего то другого в рамках кролика
Павел
Хотите 1 мессадж на 1 очередь - пожалст, хотите все мессаджи в 1 очередь - тоже можно.
Павел
Кофигурируйте как вам надо и будет результат
Михаил
Хотите 1 мессадж на 1 очередь - пожалст, хотите все мессаджи в 1 очередь - тоже можно.
А ну в таком плане да
Михаил
Вы просто не понимали этого вроде до этого
Павел
Единственное что отличает его от обычных консюмеров (и то смотря как написать консюмер с 0 самому), консюмер там один, просто с матчингом хэндлеров
Иван
если симфа не будет уметь, что она умеет, сразу же заноют, что изкаробки ничего не работает, ниточтолара
Михаил
Нууу, фантазёры. Сразу заноют
Павел
Мессенджер крутой компонент, да еще и не только для очередей и брокеров
Иван
я продвигаю идею, что не надо джунам делать свои фреймворки, надо в симфу вкатываться
а для этого совершенно точно симфа должна пулять все асинхронные сообщения в один кролик, чтобы оно просто работало, чтобы джун не слинял в ужасе от программирования ямлов
Павел
я продвигаю идею, что не надо джунам делать свои фреймворки, надо в симфу вкатываться
а для этого совершенно точно симфа должна пулять все асинхронные сообщения в один кролик, чтобы оно просто работало, чтобы джун не слинял в ужасе от программирования ямлов
Ну как сказать, когда пишешь свой фрейм из говна и палок, понимаешь +- как все работает от начало до конца. От сессий до кук, запросов и сервера.
А то будет как в Ларе - чуваки вкатываются сначало туда, а потом в php. Остальное все подкапотный мейджик
Павел
Но останавливаться на этом не надо, да.
Иван
Ну как сказать, когда пишешь свой фрейм из говна и палок, понимаешь +- как все работает от начало до конца. От сессий до кук, запросов и сервера.
А то будет как в Ларе - чуваки вкатываются сначало туда, а потом в php. Остальное все подкапотный мейджик
понимаешь, ага
все инъекции собрал, все плохие практики
Михаил
Иван
лорды и прочие серьоры каждый день контрибутят, потому что не уверены, что написанное работает действительно хорошо
Павел
понимаешь, ага
все инъекции собрал, все плохие практики
Да, но ты понял что такое плохая практика, как делать хорошо и плохо, какие есть варианты.
Любой опыт - это опыт.
Павел
Тот же роутинг написать - уже интересная задача
Иван
я надеюсь, вы для ремонта шуруповёрты покупаете?
причём покупаете самые лучшие из доступных по рынку
а не куёте сверло из арматуры
Павел
я надеюсь, вы для ремонта шуруповёрты покупаете?
причём покупаете самые лучшие из доступных по рынку
а не куёте сверло из арматуры
Ну чтобы в стуле закрутить шуруп отвалившийся - шуруповерт покупать оферхэд)
Павел
Взял нож и сделал
Михаил
Я надеюсь вы когда ищете инструмент для вашего проекта на symfony - не в строй магазин ходите?
Иван
Я надеюсь вы когда ищете инструмент для вашего проекта на symfony - не в строй магазин ходите?
я на алике беру девольты
The Ant
Ну чтобы в стуле закрутить шуруп отвалившийся - шуруповерт покупать оферхэд)
У настоящего мужчины должны быть дома пассатижи, пара отвёрток и молоток 😄
The Ant
И ключ на 19-21
Павел
У настоящего мужчины должны быть дома пассатижи, пара отвёрток и молоток 😄
))) да, молотком тоже можно шурупы "вкручивать" )))
The Ant
Ну тож норм )
Михаил
А пассатижи - они же и молоток для маленьких гвоздиков
Алексей
Понимаю что симфони это инструмент, но точно не отвёртка. Больше кухонный комбайн напоминает