Чтобы бот заработал нужно в переменные среды загрузить TELEGRAM_TOKEN
Приложение для отслеживания обновлений контента по ссылкам. При появлении новых событий отправляется уведомление в Telegram.
Проект написан на Java 23 с использованием Spring Boot 3.
Проект состоит из 2-х приложений:
- Bot
- Scrapper
Для работы требуется БД PostgreSQL, Redis, Kafka.
Для дополнительной справки: HELP.md
Бот поддерживает следующие команды:
/help— список всех доступных команд./start— регистрация пользователя./stop— удаление всех данных о чате (ID чата, отслеживаемые ссылки и т. д.)./track— добавление ссылки для отслеживания/untrack— удаление ссылки из списка отслеживаемых./list— получение списка всех отслеживаемых ссылок./tag— для просмотра всех тегов (/tag) и ссылок под конкретным тегом (/tag < tag >)
Бот общается со Scrapper API через:
ChatClient— регистрация и удаление чатов.LinkClient— управление ссылками (добавление, удаление, получение списка).TagClient— для получения списка тегов и ссылок по тегу.
Scrapper API работает по OpenAPI-контракту. В случае ошибок ошибки логируются, корректную обработку ошибок и пересылку сообщений в чат выполняет ErrorHandler.
- Бот получает обновления о ссылках через
UpdateControllerпо HTTP либо черезKafkaUpdateListenerпо Kafka. - Scrapper отправляет данные по OpenAPI-контракту.
- Обновления рассылаются чатам через
UpdateService.
- Бот поддерживает встроенное меню команд в Telegram.
Бот кеширует ответы для следующих команд:
- /tag
- /tag
- /list
🔄 Кеш автоматически сбрасывается в следующих случаях:
- При добавлении или удалении ссылки (/track, /untrack)
- При удалении чата (/stop)
При вызове команд бот сначала проверяет наличие ответа в кеше. Если данные найдены — используется кеш. В противном случае происходит обращение к Scrapper API, и результат сохраняется в кеш.
Scrapper обрабатывает запросы от бота:
- Работа с чатами через
ChatController. - Работа с ссылками через
LinkController. - Работа с тегами через
TagController.
Все контроллеры работают по OpenAPI-контракту.
UpdateScheduler.- 📡 Источники данных:
- GitHub — через
GitHubClient - Stack Overflow — через
StackOverflowClient
- GitHub — через
- ⚙️ Обработка полученных данных
- Запрос обновлений
- Для каждого URL запрашивается обновление через API
- Фильтрация обновлений
- Определяются подписанные пользователи (чаты), которые отслеживают данный URL.
- Для каждого пользователя применяется его список фильтров:
- Ключевые фильтры — фильтрация по ключевым словам (issue, commit и т.д).
- Анти-фильтры по пользователям — если указано user=username, то обновления от этого пользователя игнорируются.
- Парсинг ответа
- Полученный JSON-ответ анализируется, извлекаются значения, соответствующие фильтрам.
- Проверка актуальности
- Обновление считается релевантным, если оно произошло после последнего запуска шедулера.
- Формирование уведомлений
- Отобранные обновления, соответствующие фильтрам, отправляются пользователям либо через HTTP, либо через Kafka.
- Запрос обновлений
- ⚙️ Обработка батчей и многопоточность
- Ссылки на обновления запрашиваются партиями (batch) заданного размера. Каждый батч делится между потоками. Количество потоков настраивается через конфигурацию.
Для хранения данных используются четыре основные таблицы и три вспомогательные таблицы для связи.
chats— таблица чатов.links— таблица ссылок.tags— таблица тегов.filters— таблица фильтров.
Связи между чатами, ссылками, тегами и фильтрами реализованы через промежуточные таблицы:
chat_links— связь между чатами и ссылками.chat_link_tags— связь между ссылками и тегами в контексте чата.chat_link_filters— связь между ссылками и фильтрами в контексте чата.
💡 Один чат может отслеживать несколько ссылок, а одна ссылка может быть отслеживаемой несколькими чатами.
📌 Каждая ссылка может иметь несколько тегов и фильтров в рамках одного чата.
- SQL (
JdbcTemplate,SqlRepository). - ORM (
Hibernate,OrmRepository).
Оба репозитория (SqlRepositoryиOrmRepository) наследуются отDbRepositoryи работают одинаково.
Выбор зависит от настроек (database.access-type).