связь каждого с каждым по rest api
2. сервер с телеграмом работает только на ввод/вывод данных => вся обработка и общение с бд лежит на сервере с парсером.
3. объединить парсер с базой данных на одном сервере.
Данные в бд гоняются туда-сюда достаточно часто, хватит ли для парсера и этого одного сервера?
Какая практика вообще присутствует? Всё разделять? Или может посильнее кучковать, а не делигировать, чтобы было меньше шансов, что что-то отлетит?
а зачем вам рест между сервером и бд?
почему бы во втором варианте не поменять парсер и бд местами? парсер кидает в бд данные, бот их оттуда берет. Или вам надо чтобы бот общался с парсером?
Хм Спасибо, очень дельная мысль) Как-то не подумал Просто первоначально парсер был частью сервера с телегой И там и крутилась крон задача на парсинг каждый час Поэтому априори считал, что задачу парсеру задаёт сервер с вебхуком.. . Тогда теперь надо выбрать между первым и вторым))
ну между первым и вторым (где бд на месте парсера) разница лишь в том, общается бот с парсером или нет. Тут уж как вам нужно архитектурно
А, ну конечно Я вспомнил почему я так решил Парсер должен отправить боту новые данные для рассылки Дело в том, что невозможно заранее определить сколько парсинг займет времени (зависит от количества вводных данных == пользователей) Если бы время было фиксировано, я бы просто допустим через 5 минут после парсинга забирал бы обновленные данные с бд и делал бы рассылку
ну тогда первый вариант будет лучше, но это повлечет за собой дополнительные траты на сервер под бд
Ну это естественно, куда в наше время без денег Спасибо огромное за дельные мысли)
1 вариант это стандарт, все остальное будет приводить к ботлнеку (узкому горлышку)
Чудесно, мы с @MrOnlineCoder и @kar_enina решили так же)
вам поможет moleculer.services с кастомным транспортером
вам за рекламу платят?
увы, нет
Какой-то ультимативный вариант
у меня просто примерно такой же кейс был, тоже тг бот, тоже адовейший парсинг, но бд была rethinkdb
Обсуждают сегодня