8 источников данных вместо 5: архитектура без хаоса

Когда 8 источников данных лучше, чем 5: история добавления адаптеров в trend-analisis

Проект trend-analisis — это система для анализа трендов и выявления поднимающихся волн в интернете. Задача казалась простой: расширить количество источников данных с пяти на тринадцать. Но когда я начал работать над этим, выяснилось, что просто дописать парочку адаптеров — это полдела.

Стояла вот такая задача: система работала с базовыми источниками, но нужно было подключить Reddit, NewsAPI, Stack Overflow, YouTube, Product Hunt, Google Trends, Dev.to и PubMed. Каждый из этих сервисов имеет свой API, свои ограничения и свою логику. И всё это нужно было интегрировать так, чтобы система оставалась гибкой и не развалилась под грузом новых зависимостей.

Первым делом я распланировал архитектуру: создал три новых модуля — social.py (Reddit и YouTube), news.py (NewsAPI) и community.py (Stack Overflow, Dev.to, Product Hunt). Каждый адаптер наследует базовый класс и реализует единый интерфейс. Это позволило потом просто регистрировать их в единой системе через источник-реестр.

Неожиданно выяснилось, что обновление конфигурации — это не просто добавление новых блоков в .env. Пришлось создавать DataSourceConfig модели для каждого источника, настраивать веса категорий так, чтобы они суммировались ровно в 1.0 (иначе система вычисляет рейтинги неправильно), и регистрировать каждый адаптер в source_registry. Плюс Google Trends потребовал отдельного адаптера в search.py, а PubMed — в academic.py.

Интересный факт о том, почему асинхронный подход здесь критически важен: каждый запрос к внешнему API может занять 1–5 секунд. Если делать это синхронно, то 13 источников загружались бы последовательно — получилось бы минуту-другую ждать результаты. С aiohttp и асинхронной инициализацией адаптеры загружаются параллельно, и общее время сокращается в разы.

После написания кода пришло время проверки. Запустил 50+ unit-тестов в test_new_adapters.py — все прошли. Потом E2E-тесты в test_free_sources_e2e.py — и здесь появилась проверка: действительно ли все 13 адаптеров зарегистрированы? Запустил скрипт:

Registered adapters: 13
✓ Config loaded successfully
✓ Category weights: все суммируют к 1.0000

Всё готово. Система теперь анализирует тренды с восьми новых источников: социальные дискуссии с Reddit, новости через NewsAPI, технические вопросы со Stack Overflow, видео-тренды с YouTube, запуски продуктов с Product Hunt, поисковый интерес через Google Trends, dev-сообщество с Dev.to и научные статьи с PubMed.

Что дальше? Теперь нужно следить за качеством данных, оптимизировать частоту обновлений и убедиться, что система корректно взвешивает сигналы из разных источников. Но главное — это работает, и система готова к следующему расширению.

Если честно, в процессе я понял простую вещь: архитектура на основе адаптеров — это не просто модный подход, а жизненная необходимость. Когда каждый источник имеет свой класс и свою логику, добавить девятый источник можно за час, не трогая остальную систему.

😄 Настоящая боль не в коде, а в том, чтобы найти, кому принадлежит API ключ, который лежит в .env файле без комментариев и истории.