Реализуйте веб-хуки для массовых действий

Я хочу реализовать веб-хуки как часть REST API приложений.

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

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

Пока что я рассмотрел:

  • Просто выполняю обратный вызов для каждой сущности, используя какой-то асинхронный пул - проблема, которую я вижу здесь, заключается в масштабировании и потенциально причинении вреда тем приложениям, которые подписываются на веб-хуки.
  • Создание очереди записей об изменении для каждой регистрации веб-перехватчика, скажем, в течение 10-секундного окна, а затем отправка одного уведомления веб-перехватчика для подписки со списком затронутых сущностей - проблема, которую я вижу здесь, заключается в том, что мы вводим ненужную задержку между действием и веб-перехватчиком , когда события просто просачиваются внутрь - это также приводит к некоторым накладным расходам и сложности, особенно при реализации этого в сценарии веб-фермы.
  • Фактически представляет массовые действия как веб-перехватчики - поэтому, если массовое удаление было выполнено, потребитель подписался бы на это. Таким образом, установка ловушки для изменений отдельных сущностей не будет получать никаких событий изменения сущностей для массовых обновлений / удалений и т. Д. - им придется обрабатывать это через веб-хуки массовых действий.

В качестве дополнительных деталей - массовое действие в этом приложении, вероятно, будет охватывать от 10 до примерно 100 000 объектов.

Кто-нибудь реализовал веб-хуки для массовых действий, которые могут пролить свет на то, как они решили это реализовать?


person Bittercoder    schedule 19.09.2012    source источник
comment
У меня тоже есть все эти проблемы, плюс я просто не блокирую основную обработку HTTP при вызове веб-перехватчиков. Какое решение вы в конечном итоге использовали и есть ли у вас предложения на 2017 год? (желательно с Python / Lambda)   -  person Edwin Evans    schedule 15.12.2017


Ответы (1)


Недавно мы реализовали веб-хуки как часть нашего API для отдыха, и нас больше всего беспокоили массовые действия. В нашем случае это массовый импорт, при котором пользователь может импортировать записи в файле Excel или CSV через наше веб-приложение.

Наш процесс импорта спроектирован таким образом, что весь процесс выполняется в транзакции. Поэтому, если это не удается, мы просто откатываем назад и ничего не делаем, и если он успешно завершается, мы отправляем одно уведомление о веб-перехвате подписанному клиенту с одним огромным телом с информацией о затронутых объектах.

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

person Obaid    schedule 20.09.2012