Пост @zdanevich-vitaly — Веб-разработка — 28.06 00:22 / Хабр

Парсинг вместо API

Ботов и Telegram API автор не использует. Вообще. Парсит публичную страницу t.me — это значит, что короткие видео сохраняются, а аудио — нет. Комментарии и реакции тоже не достаются: на публичной web-версии канала их попросту нет. Зато не нужен токен бота, не нужен сервер, не нужно рейт-лимиты отслеживать.

Если у вас канал с текстовым контентом и картинками — работает. Если завязаны на аудио и обсуждения — ищите другой подход.

Генерация и деплой

Механика: GitHub Actions, раз в сутки, перегенерирует весь сайт целиком. Пост изменился в канале — меняется и на сайте, а в git-репозитории остаётся полная история правок. Никакого инкрементального билда, никакого диффа — полная пересборка каждый цикл. Для канала с сотней постов это секунды. Для тысяч — вопрос размера артефактов и лимитов бесплатного хостинга.

Дизайн — минималистичный, два варианта (чёрная и белая тема), JavaScript отсутствует напрочь. Есть пагинация, теги, отдельные страницы. Свой CSS инжектится через переменную окружения — то есть тему можно подкрутить, не форкая шаблон.

Практические детали

Определённые посты канала можно маппить в отдельные страницы сайта. Теги тоже настраиваемые. На GitHub Pages и GitLab Pages бесплатного места под статику — гигабайт, для текстового канала этого хватит надолго.

Что стоит проверить на практике:

• Как парсер переживает форматирование постов (вложенность, цитаты, опросы).

• Что происходит с постами, содержащими только пересланные сообщения.

• Стабильность на каналах с частым редактированием (сутки между перегенерациями — не мелочь).

• Поведение при превышении лимитов бесплатных минут Actions.

Проект на GitHub, ссылка есть в оригинальном посте. Код открытый.

Философия решения — типичный случай «зачем платить за VPS и поднимать Next.js, если можно раз в день гонять парсер в CI». Для портфолио, документации, архива полезных постов из канала — жизнеспособно. Для продакшн-медиа с обратной связью — нет. Выбирайте кейс под задачу.