Привязал бота к Strapi: потоки, синхронизация и локальный маппер

Как я связал бота и Strapi: история о потоках, тестах и синхронизации

Задача стояла такая: bot-social-publisher — мой проект, который вытягивает заметки о разработке и публикует их на сайт borisovai.tech. Раньше каждая заметка была независимой статьёй в Strapi. Но это было скучно. Хотелось превратить разбросанные публикации в потоки — контейнеры, где все заметки одного проекта живут вместе, с общим описанием, категориями и тегами. Типа: “Поток разработки my-project: 5 заметок, последние фичи и баг-фиксы”.

Первым делом открыл backend на Node.js + Strapi. Там уже была база под API, но нужно было достроить. Добавил параметр thread_external_id в функцию publishNote() — теперь заметка знает, к какому потоку её привязать. Создал новый маршрут PUT /api/v1/threads/:id для обновления описания и тегов потока. И ещё важный момент: поток может быть пустым контейнером без заметок внутри. Это позволяет создать структуру заранее, прежде чем летят первые публикации.

Потом переключился на Python-часть бота. Вот тут уже кипела работа. Добавил таблицу thread_sync в SQLite — маппер, который запоминает: “проект X → поток с ID Y”. Зачем это нужно? Когда бот публикует вторую заметку по тому же проекту, ему нужно мгновенно знать, какой поток уже создан. Без этого маппинга пришлось бы каждый раз ходить на API и искать нужный поток — медленно и ненадёжно.

Создал отдельный модуль ThreadSync с методом ensure_thread(). Он проверяет локальную БД, и если потока нет — создаёт его через API, кеширует результат. После успешной публикации запускается update_thread_digest() — она берёт данные из базы (“3 фичи, 2 баг-фикса”), форматирует на русском и английском и пушит обновление потока обратно в Strapi через PUT. Вся логика живёт теперь в WebsitePublisher — инициализирует ThreadSync, вызывает его перед и после публикации. Асинхронно, с aiosqlite для неблокирующего доступа к базе.

Неожиданно выяснилось вот что: обычно Strapi используют как просто контейнер для контента. А здесь я его заставляю выполнять структурирующую роль. Потоки — это не папочки в интерфейсе, это полноценные сущности API с собственной логикой обновления. Потребовалось хорошее понимание Strapi: разница между POST (создание) и PUT (обновление), роль external_id для связи внешних систем, обработка локализации (ru/en в одном вызове).

Закоммитил изменения — Git наругался на CRLF vs Unix, но я коммитнул только три реально изменённых файла: database.py, thread_sync.py, website.py. Результат: 70 тестов проходят, 1 скипнут. Система работает. Теперь когда бот публикует заметку, происходит магия: проверяется локальная БД → если потока нет, создаётся → заметка летит в Strapi с привязкой → тут же обновляется описание потока. Всё это видно на https://borisovai.tech/ru/threads.

Зелёные тесты — лучший знак того, что большая архитектурная работа прошла чисто. 😄