Иногда одного получателя вебхуков недостаточно.
В типичной конфигурации вебхук отправляется в одну систему. Платёжный сервис, CRM, GitHub, Telegram, no-code-платформа или другой внешний сервис выполняет HTTP-запрос на заранее настроенный URL. Ваше приложение получает и обрабатывает этот запрос.
Но в реальных системах часто возникает другой вопрос: что делать, если один вебхук необходимо доставить сразу в несколько мест?
Например, вы можете отправлять запросы вебхуков в основное приложение и одновременно сохранять их копии в отдельной системе для отладки или анализа. Во время миграции может потребоваться пересылать запросы и на старый, и на новый сервер. Или вы можете захотеть предоставить службе поддержки доступ к входящим событиям вебхуков, не открывая доступ к базе данных, административной панели или внутренней инфраструктуре.
Такой подход обычно называют fan-out, или разветвлением доставки: один входящий запрос принимается один раз, а затем доставляется нескольким получателям.
Когда полезно разветвление доставки вебхуков
Один из распространённых сценариев — аудит и наблюдение.
Рано или поздно вам может потребоваться предоставить другому человеку или команде возможность просматривать входящие события вебхуков. Это может быть служба поддержки, команда контроля качества, партнёр по интеграции или внешний специалист. Без отдельного промежуточного уровня для этого может понадобиться открыть им доступ к административной панели, журналам, базе данных или внутренним инструментам.
Это не всегда удобно. И не всегда безопасно.
Часто требуется более простое решение: человек должен видеть, что запрос вебхука поступил, когда это произошло, какие метод и путь использовались, какой у запроса статус и какие данные он содержал — без доступа к остальным компонентам системы.
Adal может выступать отдельным уровнем для получения и наблюдения за запросами вебхуков. Внешний сервис отправляет вебхук в Adal, а Adal пересылает его в ваше основное приложение. При этом запрос остаётся доступным в Adal для просмотра, отладки и повторной отправки.
Ещё один сценарий — хранение резервных копий входящих событий.
Если запросы вебхуков содержат важные данные, их можно отправлять нескольким получателям. Например, один получатель может вести в основное приложение, а другой — в хранилище, аналитический конвейер или внутренний сервис, сохраняющий копии событий для последующего изучения.
Это не заменяет полноценную стратегию резервного копирования, но способно снизить риск потери важного вебхука, если принимающая система завершила обработку с ошибкой или была временно недоступна.
Третий распространённый сценарий — миграция сервера.
Представьте, что вы переносите обработчик вебхуков со старого сервера на новый. Даже после обновления DNS-записи или изменения URL вебхука во внешнем сервисе переход может произойти не мгновенно. Из-за кеширования некоторые клиенты, прокси-серверы или внешние системы ещё некоторое время могут отправлять запросы на старый адрес.
В Adal можно одновременно настроить двух получателей: старый и новый серверы. Один и тот же входящий запрос будет доставляться в обе системы, пока вы проверяете, что новый сервер правильно получает и обрабатывает события.
После завершения миграции старого получателя можно отключить, не изменяя URL вебхука во внешнем сервисе ещё раз.
Переключение обработчиков без ожидания обновления DNS
Существует и более простой сценарий.
URL серверов Adal постоянны. Вы можете один раз настроить внешний сервис на отправку вебхуков в Adal, а затем управлять их дальнейшей доставкой внутри Adal.
Сегодня вебхуки можно получать локально через Adal CLI на одном компьютере. Завтра — подключиться с другого компьютера. Позже можно добавить получателя Direct HTTP и пересылать те же запросы на публичный сервер. Внешний URL вебхука при этом не изменится.
Это особенно удобно при разработке, тестировании и постепенном переходе из локальной среды в продакшен.
Вместо того чтобы каждый раз менять URL вебхука у внешнего поставщика и ждать применения новой конфигурации, достаточно обновить получателя в Adal.
Что делает Adal
Adal принимает входящий запрос вебхука, сохраняет его и доставляет настроенным получателям.
Получателем может быть локальный обработчик, подключённый через Adal CLI, или публичный HTTP-сервис с доставкой через Direct HTTP. Если настроено несколько получателей, Adal может отправить один и тот же входящий запрос сразу в несколько систем.
Таким образом, Adal выступает уровнем доставки между внешними сервисами и вашими обработчиками вебхуков.
С помощью Adal можно:
отправлять один запрос вебхука в несколько систем;
временно дублировать запросы во время миграции;
подключать отдельные среды для отладки;
просматривать входящие запросы, не открывая доступ к основному приложению;
повторно отправлять запросы, если обработчик был недоступен;
переключаться между компьютерами или серверами без изменения внешнего URL вебхука.
Если при переключении обработчиков что-то пойдёт не так, Adal всё равно сможет принять и сохранить входящий запрос. Его можно будет доставить повторно, когда нужная система станет доступна.
Итоги
Разветвление доставки вебхуков полезно, когда один входящий запрос должен быть доступен нескольким системам или командам.
Оно помогает при аудите, отладке, миграции, создании резервных копий, тестировании новых обработчиков и постепенном переходе от локальной разработки к публичному серверу.
Adal позволяет вынести эту логику за пределы приложения. Вместо разработки собственного промежуточного сервиса, хранения входящих запросов, реализации повторных попыток и постоянного изменения URL вебхуков у внешних поставщиков можно один раз направить вебхуки в Adal и управлять доставкой с помощью получателей.