Comments 12
какие конкретные случаи из вашего опыта показали, что выбранный подход с вебхуками сработал лучше, чем, например, стандартный polling или другие интеграции API, и почему? спасибо
Поллинг если что и так используется для внутреннего API.
Какие конкретно случаи? Ну например "механический шагоход инженера Ларина" из очередей, отдельного MQ-брокера и СУБД, закрученнных в отдельные Docker-контейнеры внутри кластера Kubenetes, используемый на одном из проектов для ровно такой же задачи проброса сообщений с вебхука.
Думаю разницу между кластером и 300 строчками кода сможете оценить самостоятельно.
А без шедулера в ConnectionCheck никак? Поточнее дложно быть, но про логи надо подумать.
@Service
public static class ConnectionCheck {
private long lastCheck; // last time checked (millis)
@Value("${app.webhooka.connectExpireMin}")
private int connectExpireMin;
public void markAlive() {
this.lastCheck = System.currentTimeMillis();
}
public boolean isAlive() {
return System.currentTimeMillis() -
lastCheck > 1000L * 60 * connectExpireMin;
}
}
У этого подхода есть существенный недостаток: когда после Авито вы захотите запартнериться с «Вася Пупкин &Co°», придется все переписать с нуля.
Компании "Вася Пупкин &Co" придется пройти неслабый путь прежде чем встанет необходимость получать от них событийные сообщения )
И нет, в нашем решении как раз полная отвязка от конкретных форматов сообщений, в чем и ценность.
Еще я не очень понимаю, зачем отсылать 500, пока у нас хватает способности (и ресурсов) принимать и хранить новые сообщения
Чтобы не начинать цирк с постоянным хранением на своей стороне, то что находится в памяти имеет тенденцию теряться.
500я нужна для сигнализации отправляющей стороне.
in-memory ничем не лучше локального брокера сообщений типа RabbitMQ
Лучше, хотя бы тем что брокер еще надо поднять и настроить. Ну и не стоит забывать текущие реалии, при которых брокер это тоже точка для потенциального взлома.
оттуда получить блоб с их стейктрейсом на гигабайт — обычное дело.
Думаю будет лучше получить такое в виде длинной строки, обрезав по длине и выдав код ошибки, нежели пихать через JSON-десериализацию с риском утечки памяти.
Говорю же - решение с вебхуками выстраданное ) Не на пустом месте такие подходы появляются.
Речь не про формат, речь про завышенные ожидания от той стороны.
Ну не знаю что тут сказать, совсем дураков туда не берут. И ревью кода говорят там есть. И аудит. И мониторинг нагрузки.
Вопрос был «зачем хардкод, пока можем сохранить у себя».
Потому что любое локальное хранение (включая брокер) это внезапно состояние. Т.е пришедшее сообщение, сохраненное сообщение и отправленное брокером - три разных состояния одних и тех же данных.
Я же пытаюсь эти состояния сократить, чтобы не возиться с синхронизацией и версионностью данных. И не хочу например выяснять "кто прав" когда сообщение уже было сохранено локально в брокере, а затем получена его копия - из-за сбоя при получении.
Транзакции это сложно, хранение данных это сложно, так что чем меньше будет такой логики тем надежнее будет система.
Это внутренний брокер, алё. Его из интернета не видно.
Это очень опасное заблуждение )
Ваш компьютер или CI тоже не видно из интернета, но зловредный код туда все равно проникает, стоит лишь сделать npm install
В случае брокера приедет специально сформированное сообщение, с выполнением кода и вы получите reverse shell прямо в брокере - см. статью выше.
Круто, то есть, у вас совсем нет внутреннего состояния?
Минимально возможное. Выше в комментах показали как можно даже от шедулера отказаться.
У меня нет привычки выполнять
npm installв докере с RabbitMQ.
Тут как с вождением мотоцикла: можно конечно научиться безопасно его водить, но от окружающих дебилов на КАМАЗах это не спасет.
С ИБ все тоже самое.
вам пишут люди, у которых опыта общения с вебхуками явно больше вашего,
Ну и зачем было так палиться?
Работа с вебхуками и интеграциями — удел новичков и студентов, рассадник дичи, треша и говнокода. Я-то еще ладно — работа такая: чужие авгиевы конюшни разгребать.
Но вас‑то какая нелегкая заставила в это лезть, еще и "с опытом" ? Вы же «гений‑функциональщик» и все такое.
Зачем?
Вебхук слева