холивара_для._api_vs_шина_сообщений.1542832690.txt.gz | Хозяин: nikolay_carbonsoft1 | Изменен: 20.05.2019 15:18 nikolay_carbonsoft1 | Утвержден(nikolay_carbonsoft1 2018/11/21 15:38)
Новейший утвержденный

Это старая версия документа.

Обсуждение

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 в патерны

Nikolay CarbonsoftNikolay Carbonsoft, 04.10.2021 11:13

Я просто сравнил теплое с мягким немного. Я не сравнивал REST API vs вызов-процедур-через-шину. Тут действительно получается асинхронка, таймауты и прочие стремные вещи, которые во многом схожи с REST API при применении микросервисов, и если сделать умную шину, которая будет заодно контролировать и мониторить работу микросервисов…

Я скорее имел в виду движение в сторону работы с job'ами, вместо вызова API или даже переход на декларативное описание (но тут уже не шина будет, а СУБД, хотя для таких вещей подойдет какой-нибудь NoSQL). И да, еще не понятно что проще: REST API или job. Джоб сильно увеличивает качество абстрагирования, но у вызывающего появляется появляется сложная сущность job, которая может сильно повлиять на ее архитектуру (для web-приложения, это хранение job в своей БД или в сессии пользователя, периодическая проверка состояния, вывод пользователю статуса job'а итд).

А переход на декларативное описание - схожий метод, что был применен в системе интеграции с оборудованием, когда евенты заменили скриптом-синхронизатором. Дополнительной фичей тут будет разбиение на системы, которое доступно для администратора - REST API, обычно, дебажит разработчик, а упавший job в супервизоре - админ.

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