Коля, большое спасибо за то, что делишься знаниями и опытом. Очень важная теория изложена в докладе. Нашел много ответов на вопросы, возникшие в процессе обдумывания микросервисной архитектуры.
Тоже пришёл к идее, что разработка делится на event-driven и command-driven, или, что равнозначно - асинхронный и синхронный подходы. В основном все программируют в синхронном виде. Но практика показывает, что асинхронные сервера гораздо быстрее и естественнее. Синхронный подход не нормален для распределённых архитектур и для серверов в целом. Синхронный подход всё соединяет единой лапшой связей, и получается спагетти-монстр, монолит, хоть и сшитый из сетевых соединений между модулями. А всё потому, что команды создают ПРЯМЫЕ связи между компонентами. Компоненты должны знать друг о друге, что и создаёт связность, от которой многие хотели бы избавиться при распределённой серверной архитектуре. Всё это в целом говорит о том, что сервера необходимо программировать асинхронными и событийно-ориентированными. А иначе вас ждут боль и страдания. Синхронное программирование годится только для программирования отдельных функций, но никак не серверного кода. В чём коренное отличие команды и события? Команда (как и любое сообщение) имеет адресата, а событие адресата не имеет! Событие - это сообщение, не имеющее адресата. Это даёт возможность каждому модулю не думать о других модулях. Он просто отправляет события, и ему всё равно, как и кто его обработает. Это убирает прямые связи и зависимости между модулями, позволяя легко их добавлять или убирать без вреда для других модулей. Это ли не мечта программиста? Уверен, event-driven подход - это будущее, к которому все рано или поздно придут при написании серверного кода. Сам пока не реализовал эту идею, но она мне кажется очень естественной и правильной. Нахожусь в стадии доработки архитектурной идеи своего node js мини-фреймворка на этом подходе.
При совмещении event notification & event carried state transfer можно changeset`ы кидать не с timestamps. а с version, при условии оптимистичной блокировки в базе "источнике" - нормально работает. Другой вопрос, что организация таких changeset`ов - затрагивает изменение и бэка, и фронта.
Автор доклада в бувальном смысле пересказывал выступление Мартина Фаулера из далекого 2017 года, и там действительно упоминался гит. Только суть не в том, как гит фактически хранит изменения на диске - не это основа примера. Ивент сорсинг там в контексте того, что есть история коммитов, восприизведение/откат которых переводит систему в определенное состояние на тот или иной момент времени. Так что пример отличный, просто хреново пересказанный.
Были бы опытные люди проблем бы не было. У меня никогда не было единной базы данных в последние 10 лет как минимум. Ето ежу понятно! Если человек опытны.. Почему нельзя было нанять в компанию людей с 25 летним стажам?? почему неопытный молодняк решает все ?? Или компания боится опытных людей? Коррупция
Это повсеместная любовь IT докладчиков вставлять в русскоязычный доклад английские фразочки похожа на русско-американский муржик с Брайтон-Бич "послайсайте мне писиками пожалуйста".Коллеги, нужно не только в технических, но и коммуникативных навыках расти.
Коля, большое спасибо за то, что делишься знаниями и опытом. Очень важная теория изложена в докладе. Нашел много ответов на вопросы, возникшие в процессе обдумывания микросервисной архитектуры.
Тоже пришёл к идее, что разработка делится на event-driven и command-driven, или, что равнозначно - асинхронный и синхронный подходы. В основном все программируют в синхронном виде. Но практика показывает, что асинхронные сервера гораздо быстрее и естественнее. Синхронный подход не нормален для распределённых архитектур и для серверов в целом. Синхронный подход всё соединяет единой лапшой связей, и получается спагетти-монстр, монолит, хоть и сшитый из сетевых соединений между модулями. А всё потому, что команды создают ПРЯМЫЕ связи между компонентами. Компоненты должны знать друг о друге, что и создаёт связность, от которой многие хотели бы избавиться при распределённой серверной архитектуре. Всё это в целом говорит о том, что сервера необходимо программировать асинхронными и событийно-ориентированными. А иначе вас ждут боль и страдания. Синхронное программирование годится только для программирования отдельных функций, но никак не серверного кода.
В чём коренное отличие команды и события? Команда (как и любое сообщение) имеет адресата, а событие адресата не имеет! Событие - это сообщение, не имеющее адресата. Это даёт возможность каждому модулю не думать о других модулях. Он просто отправляет события, и ему всё равно, как и кто его обработает. Это убирает прямые связи и зависимости между модулями, позволяя легко их добавлять или убирать без вреда для других модулей. Это ли не мечта программиста?
Уверен, event-driven подход - это будущее, к которому все рано или поздно придут при написании серверного кода. Сам пока не реализовал эту идею, но она мне кажется очень естественной и правильной. Нахожусь в стадии доработки архитектурной идеи своего node js мини-фреймворка на этом подходе.
Я кстати ,знаю откуда это все идет , с какой темы😂😂😂😂 просто это было давно придумано из другой схемы.
Отличный доклад - автор молодец шарит!
бедный оператор
Отличный доклад. Николай - молодец!
При совмещении event notification & event carried state transfer можно changeset`ы кидать не с timestamps. а с version, при условии оптимистичной блокировки в базе "источнике" - нормально работает. Другой вопрос, что организация таких changeset`ов - затрагивает изменение и бэка, и фронта.
Мужик с таким умным лицом говорит 😂
Прекрасный доклад , спасибо автору👍🏻
По моему докладчик путает redis с rabbitmq
не?
или в редисе тоже теперь можно очереди делать?
можно
редис умеет в паб\саб
Когда у тебя полезной информации максимум на 2 минуты, просто бегай 40 минут туда-сюда по сцене.
Отдыхай через каждые две минуты и твой гипоталамус не будет перегружаться)
В git не хранятся дельты изменений. Там хранятся содержимое самих файлов в сжатом виде - состояния. Так что git это НЕ пример event source-инга
Автор доклада в бувальном смысле пересказывал выступление Мартина Фаулера из далекого 2017 года, и там действительно упоминался гит. Только суть не в том, как гит фактически хранит изменения на диске - не это основа примера. Ивент сорсинг там в контексте того, что есть история коммитов, восприизведение/откат которых переводит систему в определенное состояние на тот или иной момент времени. Так что пример отличный, просто хреново пересказанный.
хорошему докладчику не хватает относительной статики .
на загнивающем западе докладчики только так по сцене перебегают
это видимо нужно для концентрации внимания слушателей, чтоб не было статики
20:25 но-но-но! нехороший пример.
Были бы опытные люди проблем бы не было. У меня никогда не было единной базы данных в последние 10 лет как минимум. Ето ежу понятно! Если человек опытны.. Почему нельзя было нанять в компанию людей с 25 летним стажам?? почему неопытный молодняк решает все ?? Или компания боится опытных людей? Коррупция
как-то очень скомканно
Нарамально
Это повсеместная любовь IT докладчиков вставлять в русскоязычный доклад английские фразочки похожа на русско-американский муржик с Брайтон-Бич "послайсайте мне писиками пожалуйста".Коллеги, нужно не только в технических, но и коммуникативных навыках расти.