Event-Driven Software Architecture

Developer I Certification Maintenance (Summer '19) модуль вывел меня Platform Events Basics модуль. В общем я и раньше читал про Streaming API, но подписку на PushTopics и Platform Events я исключительно воспринимал в виде сервер-отправитель и брузерное приложение-подписчик.

но в модуле пишут что подписчик не обязательно клиентский браузер, это может быть и стороннее серверное приложение.

более того вся эта логика "выпуск эвентов в event bus и подписка на этот канал" может быть предназначена исключительно для выполнения логики внутри самого орга.

это интересный подход, и он вызывает интересные идеи, конечная цель которых - это упрощение кода и снижение зависимостей, но пока я еще не могу сложить все в единую картину.

первое, как Event-Driven Architecture может помочь в интеграции. Мне кажется, что подписку на канал можно использовать в случае интеграции по принципу fire-forget, когда не требуется обратная связь от получателя сообщения. И кажется что интеграция по принципу подписки на канал проще SOAP or REST интеграции.

второе, внутри орга этот event bus создает какой-то промежуточный слой между разными частями приложения, они теперь не связаны напрямую, и сам процесс подключение к каналу требует действий только на стороне подписчика, а не эмитера сообщения. Получается такая связь от-Многих-ко-Многим, при этом каждый конец этой связи не зависит от другого конца. Это вероятно помогло бы в избавлении зависимости например между пакетами.

В общем Event-Driven Software Architecture кажется интересной идеей, что думаете?

Den Brown

Developer I Certification Maintenance (Summer '19) модуль вывел меня [url=https://trailhead.salesforce.com/content/learn/modules/platform_events_basics]Platform Events Basics[/url] модуль. В общем я и раньше читал про  [url=https://trailhead.salesforce.com/content/learn/modules/api_basics/api_basics_streaming]Streaming API[/url], но подписку на  PushTopics и Platform Events я исключительно воспринимал в виде [i]сервер-отправитель и брузерное приложение-подписчик[/i].

но в модуле пишут что подписчик не обязательно клиентский браузер, это может быть и стороннее серверное приложение.

более того вся эта логика "выпуск эвентов в event bus и подписка на этот канал" может быть предназначена исключительно для выполнения логики внутри самого орга.

это интересный подход, и он вызывает интересные идеи, конечная цель которых - это упрощение кода и снижение зависимостей, но пока я еще не могу сложить все в единую картину.

первое, как Event-Driven Architecture может помочь в интеграции. Мне кажется, что подписку на канал можно использовать в случае интеграции по принципу fire-forget, когда не требуется обратная связь от получателя сообщения. И кажется что интеграция по принципу подписки на канал проще SOAP or REST интеграции. 

второе,  внутри орга [b]этот event[/b] bus создает какой-то промежуточный слой между разными частями приложения, они теперь не связаны напрямую, и сам процесс подключение к каналу требует действий только на стороне подписчика, а не эмитера сообщения. Получается такая связь [b]от-Многих-ко-Многим[/b], при этом каждый конец этой связи не зависит от другого конца. Это вероятно помогло бы в избавлении зависимости например между пакетами.

В общем Event-Driven Software Architecture кажется интересной идеей, что думаете?

Используем Streaming API в проекте на серверной стороне в NodeJS бэкенде. Впечатления двоякие. С одной стороны Вау эффект - получать Events мгновенно! А с другой стороны какой-же это гемор - работает через раз. То события по непонятной причине не приходят, то валятся какие-то непонятные ошибки, о которых в интернете ни слова как разрулить (особенно на сандбоксах работает как попало, с dev оргами и продами еще более менее). Есть лимиты в которые тоже вполне реально упереться и надо про это знать.
В общем если использовать эту технологию то только как вспомогательный инструмент или в элементах приложения где не очень важно 100% получение events.
Если все же хочется использовать, то советую присмотреться к
Change Data Capture
Это недавно введенный тип Events и в отличии от PushTopics должен работать намного эффективнее.

Dmitry Shnyrev

Используем Streaming API в проекте на серверной стороне в NodeJS бэкенде. Впечатления двоякие. С одной стороны Вау эффект - получать Events мгновенно! А с другой стороны какой-же это гемор - работает через раз. То события по непонятной причине не приходят, то валятся какие-то непонятные ошибки, о которых в интернете ни слова как разрулить (особенно на сандбоксах работает как попало, с dev оргами и продами еще более менее). Есть лимиты в которые тоже вполне реально упереться и надо про это знать.
В общем если использовать эту технологию то только как вспомогательный инструмент или в элементах приложения где не очень важно 100% получение events.
Если все же хочется использовать, то советую присмотреться к
[url=https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm]Change Data Capture[/url]
Это недавно введенный тип Events и в отличии от PushTopics должен работать намного эффективнее.

Это относительно новая фича с отловом внутри орга. Пока попользоваться на практике не удалось. Streaming API для фронт енда давно пользовался, очень удобно.
советую как говорит Дима очень внимательно присмотреться к лимитам прежде чем перестраивать всю архитектуру под event driven

Андрей

Это относительно новая фича с отловом внутри орга. Пока попользоваться на практике не удалось. Streaming API для фронт енда давно пользовался, очень удобно.
советую как говорит Дима очень внимательно присмотреться к лимитам прежде чем перестраивать всю архитектуру под event driven