Она отлично работает, мы ее используем в консюмерах, там где соединение устанавливается 1н раз и держится постоянно, но в режиме request/response эта либа не дает возможности держать постоянное соединение(
Действительно, есть огромный соблазн использовать самописную прокси, написанную за полчаса на Гошке, которая жрёт оперативки в 100 раз меньше, но мы пока что не имели возможности выделить времени на тестирование стабильности работы такого решения в продакшене.
В целом, написал так потому что, практически все проекты о которых я слышал, используют именно RabbitMQ, в том числе туториалы для начинающих также описывают работу с очередями на базе RabbitMQ.
RabbitMQ использует протокол amqp - который также является достаточно затратным для установки соединения, но на моей практике - проблем это не вызывало.
С RabbitMQ начинаются проблемы, когда начинается работа с 10+к сообщений в секунду или же когда хочется большие сообщения пересылать(500kb+).
Кто-то даже сделал форк на гитхабе и воплотил все описанные выше комментарии в жизнь)
---
Не думаю что переданный конфиг в data - хоть как то замедлит игровой процесс, так же как и выбор как следить за стораджом(watch или computed), как по мне это уже больше экономия на спичках и вкусовщина.
----
Напомню что, цель статьи была - показать как легко и просто можно реализовать обмен данными между Vue и игрой на Phaser
Количество сообщений которое мы предполагаем слать в моменте - незначительное(~50-150/min).
Я полностью согласен с тем что, нужно в первую очередь отталкиваться от функциональных/не функциональных требований. В нашем случае брокер сообщений используется в качестве буфера уведомлений о событиях(из реального мира) и мы заранее не можем предугадать сколько будет клиентов и в какой момент он подключится(в силу разных причин).
Исходя из условия что мы не имеем жестких ограничений основанных на функциональных требованиях, плюс имея выгоду, в том плане что каждый клиент может иметь свой consumer.group_id и читать то что ему интересно в удобное ему время, то перед нами стоял лишь вопрос - сможет ли Kafka соответствовать нашим базовым потребностям.
Имеет - уже!)
доступно с версии - 6.2
А статья о 6.0 версии симфы
Мы её и используем)
Она отлично работает, мы ее используем в консюмерах, там где соединение устанавливается 1н раз и держится постоянно, но в режиме request/response эта либа не дает возможности держать постоянное соединение(
Действительно, есть огромный соблазн использовать самописную прокси, написанную за полчаса на Гошке, которая жрёт оперативки в 100 раз меньше, но мы пока что не имели возможности выделить времени на тестирование стабильности работы такого решения в продакшене.
php - умеет держать persistent connection по amqp протоколу, а с Kafka - такого пока не придумали.
В целом, написал так потому что, практически все проекты о которых я слышал, используют именно RabbitMQ, в том числе туториалы для начинающих также описывают работу с очередями на базе RabbitMQ.
RabbitMQ использует протокол amqp - который также является достаточно затратным для установки соединения, но на моей практике - проблем это не вызывало.
С RabbitMQ начинаются проблемы, когда начинается работа с 10+к сообщений в секунду или же когда хочется большие сообщения пересылать(500kb+).
Иные команды в компании имеют потребность использовать Kafka и для того чтобы не раздувать зоопарк технологий - решили остановится на этой технологии.
Писал об этом в другой своей статье, линк на неё в самом начале)
Спасибо за комментарии, все они уместные)
Кто-то даже сделал форк на гитхабе и воплотил все описанные выше комментарии в жизнь)
---
Не думаю что переданный конфиг в data - хоть как то замедлит игровой процесс, так же как и выбор как следить за стораджом(watch или computed), как по мне это уже больше экономия на спичках и вкусовщина.
----
Напомню что, цель статьи была - показать как легко и просто можно реализовать обмен данными между Vue и игрой на Phaser
извините, всегда нервничаю перед публикацией и публикую не перечитывая.
Поправлю)
Количество сообщений которое мы предполагаем слать в моменте - незначительное(~50-150/min).
Я полностью согласен с тем что, нужно в первую очередь отталкиваться от функциональных/не функциональных требований. В нашем случае брокер сообщений используется в качестве буфера уведомлений о событиях(из реального мира) и мы заранее не можем предугадать сколько будет клиентов и в какой момент он подключится(в силу разных причин).
Исходя из условия что мы не имеем жестких ограничений основанных на функциональных требованиях, плюс имея выгоду, в том плане что каждый клиент может иметь свой consumer.group_id и читать то что ему интересно в удобное ему время, то перед нами стоял лишь вопрос - сможет ли Kafka соответствовать нашим базовым потребностям.