Холивара для. API vs шина сообщений

Мысли, почему система, где сервисы общаются через общую шину сообщений проще, чем где общение идет через API.

В системе с API/REST системы синхронно друг к другу обращаются, для этого:

  1. требуется обработка ошибок на всех уровнях (допустим процесс А вызывает Б а тот вызывает В)
  2. плюс обработка таймаутов
  3. плюс логгирование ошибок (pl7: логированием занимается вызывающая сторона) т.е в вызывающей стороне должно быть понимание какие ошибки могут произойти на вызываемой стороне как об этом лучше сообщить и что делать вообще

В системе с сообщениями, у процесса есть шина, он кладет в нее запрос. В результате может появится:

  1. ответ с результатом
  2. ошибка (уже сформированная обрабатывающей стороной, в едином формате более менее)
  3. или таймаут (который, как мне кажется, будет более естественно выглядеть в этой конфигурации). А процесс, который обрабатывает сообщения, сам занимается из получением, сам их обрабатывает, сам обрабатывает свои внештатные ситуации (про которые он в курсе), сам ведет свои логи и знает куда и как сообщать об ошибках.

Поэтому мне и кажется, что система на общей шине будет проще и легче, чем система построенная на API.

~~OWNERAPPROVE~~

Прочитал обсуждения.blog Холивара для. API vs шина сообщений
Yes(1) No(0) Clear

Yes:
,

No:

adminadmin, 21.11.2018 19:11

с точки зрения разработки, практика как правило обратная, с очередью получается сложнее кодить и сложнее код.

требуется обработка ошибок на всех уровнях

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

плюс обработка таймаутов

в шине тоже есть обработка таймаутов

уже сформированная обрабатывающей стороной, в едином формате более менее)

чем строже тем сложнее расширять, уровень шины становится умным и специфицированным

А процесс, который обрабатывает сообщения, сам занимается из получением, сам их обрабатывает.

Возникает асинхронка, это всегда сложнее кодить, особенно джунерам

Поэтому мне и кажется, что система на общей шине будет проще и легче, чем система построенная на API

Мне кажется, что тебе только кажется. Это разные способы общения подсистем, с точки зрения простоты кода call api проще и шина нужна там где call не справляется.

Например шина нужна там, где много событий и есть несколько слушателей которые хотят подписаться на события.

p.s. шина технологичней и универсальней, но никак не проще, если хочешь можно разобрать на примерах.

adminadmin, 21.11.2018 19:26 (04.12.2018 07:21)

кстати шина(среда) с сообщениями меж подсистем(объектов) это тру идеолога ооп))

опять же по современным меркам это всего лишь один из патернов.

pl7 пропагандирует другой подход

  • есть данные, есть задачи(или tobe состояния), и есть обработчики.
  • Очередь задач с ее обработчиком это подсистема, обработчик в отличии от ооп не содержит состояний и может быть перезагружен или распараллелен.
  • У нескольких подсистем могут быть общие данные.
  • Методы и проперти это лишь удобные патерны кода, а не архитектуры.
  • А причем здесь шина? а не причем просто навеяло)

TODO перенести в PL7 в патерны

Ваш комментарий. Вики-синтаксис разрешён: