Comments 16
Довольно простой и интересный проект. Будут в будущем статьи, как ты его улучшал и сколько было расходов и доходов?
А почему бот, а не сайт?
Для быстрого уведомления пользователей. В данный момент среднее время от публикации вакансии в чат, до отправки этой вакансии пользователю меньше одной минуты, где бОльшую часть времени занимает ожидание ответа от GPT.
По своему опыту знаю, что компании рассматривают вакансии неделями. Ваши секунды реально что-то решают?
Имхо, любое сэкономленное время что-то решает.
Мне кажется вы не совсем верно поняли специфику чат-бота. Для поиска актуальных фриланс-заказов оперативность отклика является важным фактором. Для этих целей иметь возможность отсылать уведомления - лучшее решение.
Если бы это был сервис для поиска сотрудников компаниями - тогда я могу с вами согласится, что сайт имел бы место. Компании правда могу искать сотрудников месяцами. А так это другая сфера и другие задачи.
В данном случае непонятно зачем вам вообще разделение на "бот" и "апи". А по архитектуре могу предположить, что схема из курса спроектирована для возможности расширения и масштабирования, чего ваш вариант не даёт или приводит к бОльшей связности. Например, если в систему добавится новый клиент, помимо сущности "бот" (например, добавим сущность "админка"), то по схеме из курса она будет связана только с "апи", а по вашей, если только с "апи" то кто-то будет получать неконстстентные данные, то есть придётся и админке ходить ещё и в редис и решать вопрос с синхронизацией кешей.
То есть в текущих условиях ваша схема - норм (только разделение на "бот" и "апи" лишнее получается). А если расширяться, то схема из курса спроектирована лучше :).
C апи общаются все сервисы. А ботов в системе на данный момент 12 штук. В моем конкретном случае редис снимает нагрузку на апи в этих случаях:
Бот не ходит к апи на каждое сообщение от пользователя, что бы поднянуть его данные, он ходит в апи один раз и далее сохраняет у себя в кеше, т.е. пока происходит непосредственно переписка между юзером и ботом - данные юзера хранятся в кеше.
Парсер ходит в апи, что бы получить те каналы, в которых необходимо слушать вакансии. Так как занесение новых каналов происходит через админку, и порционно, то кеш в этом случае позволяет ходить в апи за "актуализацией" списка каналов 2 раза в сутки, остальное время он берет их редиса
Но не могу не отметить, что в процессе отладки была парочка багов, именно из-за проблем с синхронизацией кешей.
Спасибо за фидбек.
У бота есть Scheduler, или планировщик. Каждые 10 минут он мониторит подписки и сообщает пользователям с истёкшей подпиской, что пора купить новую.
А подписка кратна одному дню? Или можно оформить подписку только на 10 минут? Или на 40 минут?
Я это к тому, что шедулер каждые 10 мин, наверно слишком часто, как мне кажется.
Боты на каких библиотеках сделаны?
Для чего держать бд, если она не используется. Может быть все перенести в редис и откатся от бд? Хотя лучше отказаться от редиса и оптимизировать бд.
Не совсем понял, с чего вы взяли что бд не используется. На данный момент в базе около 8ми табличек, не считая таблиц связи. Редис используется как кэш, и хранит в себе данные от 1ой минуты, до 1го дня, в зависимости от сервиса, который его использует.
К тому же в качестве панели администратора развернута джанго-админ, которой необходимо наличие БД для работы.
А можно немного технических подробностей как вы подключились к GPT ? Какой сервис/api использовали?
Из пет-проекта в источник дохода: как я создал чат-бот для поиска вакансий