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°», придется все переписать с нуля.
Еще я не очень понимаю, зачем отсылать 500, пока у нас хватает способности (и ресурсов) принимать и хранить новые сообщения (вы же даже сами пишете: «технически нет никакой проблемы держать в памяти хоть миллионы сообщений»). Ну и да, отсекать надо не по messageСount, конечно, а по storedMessagesSize, но это детали.
Что не детали (говорю на основе собственного опыта работы с самыми разными сторонними сервисами, умеющими в вебхуки, общим числом более 40–50):
▸ in-memory ничем не лучше локального брокера сообщений типа RabbitMQ; хоть прям рядом поднимите: вот вам и другой порт, и хранилище пока клиент отвалился, и real-time, если клиенту зачем-то надо — вместо поллинга. Кластеры, килобаксы и прочая херня тут ни при чем, RabbitMQ встанет как влитой из коробки, с бесплатным мониторингом и разными микшируемыми как угодно очередями (это может потребоваться), с оверхедом значительно меньшим вашего наколеночного хранилища.
▸ приёмник должен быть готов к сошедшему с ума отправителю вебхуков, даже если с той сторон трижды Авито, Яндекс, Гугл. Гитхаб меня спамил, Гугл присылал правдоподобные но кривые джейсоны. Про финтеховских партнеров я и не говорю, оттуда получить блоб с их стейктрейсом на гигабайт — обычное дело.
В остальном — разумно, конечно.
У этого подхода есть существенный недостаток: когда после Авито вы захотите запартнериться с «Вася Пупкин &Co°», придется все переписать с нуля.
Компании "Вася Пупкин &Co" придется пройти неслабый путь прежде чем встанет необходимость получать от них событийные сообщения )
И нет, в нашем решении как раз полная отвязка от конкретных форматов сообщений, в чем и ценность.
Еще я не очень понимаю, зачем отсылать 500, пока у нас хватает способности (и ресурсов) принимать и хранить новые сообщения
Чтобы не начинать цирк с постоянным хранением на своей стороне, то что находится в памяти имеет тенденцию теряться.
500я нужна для сигнализации отправляющей стороне.
in-memory ничем не лучше локального брокера сообщений типа RabbitMQ
Лучше, хотя бы тем что брокер еще надо поднять и настроить. Ну и не стоит забывать текущие реалии, при которых брокер это тоже точка для потенциального взлома.
оттуда получить блоб с их стейктрейсом на гигабайт — обычное дело.
Думаю будет лучше получить такое в виде длинной строки, обрезав по длине и выдав код ошибки, нежели пихать через JSON-десериализацию с риском утечки памяти.
Говорю же - решение с вебхуками выстраданное ) Не на пустом месте такие подходы появляются.
в нашем решении как раз полная отвязка от конкретных форматов сообщений
Речь не про формат, речь про завышенные ожидания от той стороны.
500я нужна для сигнализации отправляющей стороне
Спасибо, буду знать. Вопрос был «зачем хардкод, пока можем сохранить у себя».
брокер это тоже точка для потенциального взлома
Это внутренний брокер, алё. Его из интернета не видно. Про поднять и настроить я уже говорил: это быстрее и проще, чем свой сторадж.
будет лучше получить такое в виде длинной строки
Мне мать писала, что через интернет по протоколу HTTP ходят строки примерно всегда. Не знаю, что значит «обрезав по длине», знакомые моэли тоже не в курсе, принять всю строку (пока вы не напишете свой HTTP-сервер) придется палюбасу.
Что делать с ней потом — да что угодно, я вроде не предлагал запихнуть ее в десериализатор. Я просто сказал, что к этому имеет смысл быть готовым.
Речь не про формат, речь про завышенные ожидания от той стороны.
Ну не знаю что тут сказать, совсем дураков туда не берут. И ревью кода говорят там есть. И аудит. И мониторинг нагрузки.
Вопрос был «зачем хардкод, пока можем сохранить у себя».
Потому что любое локальное хранение (включая брокер) это внезапно состояние. Т.е пришедшее сообщение, сохраненное сообщение и отправленное брокером - три разных состояния одних и тех же данных.
Я же пытаюсь эти состояния сократить, чтобы не возиться с синхронизацией и версионностью данных. И не хочу например выяснять "кто прав" когда сообщение уже было сохранено локально в брокере, а затем получена его копия - из-за сбоя при получении.
Транзакции это сложно, хранение данных это сложно, так что чем меньше будет такой логики тем надежнее будет система.
Это внутренний брокер, алё. Его из интернета не видно.
Это очень опасное заблуждение )
Ваш компьютер или CI тоже не видно из интернета, но зловредный код туда все равно проникает, стоит лишь сделать npm install
В случае брокера приедет специально сформированное сообщение, с выполнением кода и вы получите reverse shell прямо в брокере - см. статью выше.
Я же пытаюсь эти состояния сократить, чтобы не возиться с синхронизацией и версионностью данных.
Круто, то есть, у вас совсем нет внутреннего состояния? Для справки: логика обработки трех сообщений, не дождавшихся своего полла, и ста тысяч — одинаковая.
Это очень опасное заблуждение
У меня нет привычки выполнять npm install в докере с RabbitMQ.
приедет специально сформированное сообщение
Откуда приедет? Туда сообщения приезжают только из вашего собственного сервиса.
Вы читаете вообще, что вам пишут люди, у которых опыта общения с вебхуками явно больше вашего, и он значительно разностороннее? Если нет — I am good, просто не нужно делать вид, что вы поддерживаете беседу.
Круто, то есть, у вас совсем нет внутреннего состояния?
Минимально возможное. Выше в комментах показали как можно даже от шедулера отказаться.
У меня нет привычки выполнять
npm installв докере с RabbitMQ.
Тут как с вождением мотоцикла: можно конечно научиться безопасно его водить, но от окружающих дебилов на КАМАЗах это не спасет.
С ИБ все тоже самое.
вам пишут люди, у которых опыта общения с вебхуками явно больше вашего,
Ну и зачем было так палиться?
Работа с вебхуками и интеграциями — удел новичков и студентов, рассадник дичи, треша и говнокода. Я-то еще ладно — работа такая: чужие авгиевы конюшни разгребать.
Но вас‑то какая нелегкая заставила в это лезть, еще и "с опытом" ? Вы же «гений‑функциональщик» и все такое.
Зачем?
Вы же «гений‑функциональщик» и все такое.
Чаво? Никогда не был «функциональщиком» и мне всегда хватало ума заходить только в те комнаты, где я — один из самых тупых.
Работа с вебхуками и интеграциями — удел новичков и студентов, рассадник дичи, треша и говнокода.
В компаниях, которые находят свой интерес в том, чтобы платить мне зарплату, скорее всего, считали, что если интеграции с R&C и провайдерами данных доверить студенту, то с бизнесом может что-нибудь пойти не так. А, как я уже говорил, сертифицированный в ЕС R&C — это даже не Гугл, они такой дичью ваши эндпоинты начнут кормить, что вам попытка внедрить зловред — покажется меньшим из зол. Такое ощущение, что получить сертификат без красного диплома дегенеративности просто не получается.
del
Вебхук слева