#рабочийкейс #нерабочийкейс

Наверняка у многих есть кроме рабочих проектов еще и какие-то пет проекты, которые пилятся в свободное время или пилятся первое время, а потом забивают на них 😏

Вот и у меня есть такой. Правда начинал его не я и он ближе к стартапу, но отношение у меня к нему такое, так как я изучаю новое на нем и ставлю эксперименты. Углубляться не буду в его суть, а расскажу про реализацию одной интересной задачи 🍔

Дано: а) Веб-приложение на фастапи (кстати с нуля переписал первый раз на этот фреймворк с джанго) + БД посгрес; б) телеграм бот пишущий свою БД в sqlite.

Проблемы:

1. Главная проблема - и бэк, и бот выполняют +- одинаковый функционал и обращаются к внешнему апи с долгим респонсом. Кроме того, у внешнего апи ограничение на 10 потоков, поэтому в пиковое время часть запросов не обрабатываются и возвращается ошибка.

2. Для решения первого пункта будет уместно объединить БД (бот и бэк будут писать и читать из посгреса) для унификации запросов.

3. На бэке аутентификации через почту, в телеге - телега 🤪 Опять же, нужен универсальный метод

Я долго не хотел подступаться к этой задаче, так как было только общее понимание что делать, но никогда такого не делал (частично что-то из пунктов выше делал).
Ну и знаете че помогло?
СЕЛ И НАЧАЛ РИСОВАТЬ СХЕМКИ И КАК ПОЕХАЛО

Шаги реализации:

1. Составили план общей БД

2. Почитали и попробовали реббит для очередей для долгих запросов. Поняли как ограничить очередь на 10 потоков и создали рабочий прототип. Нам подошло

3. Реализация в "проде" началась тут - решили убрать аутентификацию по почте и сделать через телеграм. Я тут больше боялся, оказалось все вообще просто и за пару часов уже все работало. Соответственно первые изменения в БД - заменили почту на телеграм айди.

4. Выпиливание из бэка и бота логики запроса и обработки к внешнему апи. Перенос этой логики в консьюмер. Теперь паблишеры (бэк и бот) отправляют всю нужную инфу в сообщении, а консьюмер ее:
- обрабатывает
- отправляет в апи
- получает ответ
- сохраняет в БД нужные данные
- подтверждает обработку сообщения
- (в случае с ботом еще отправляет юзеру ответ с результатом).

ВСЕ, бэк с ботом работают дальше не ожидая долгого запроса.

5. Теперь, как мне показалось, самое сложное. В БД бота уже есть записи, которые нужно перенести в новую общую БД и структуры таблиц отличаются (напомню у бота склайт, новая - посгрес). А оказалось все просто) На питоне подключаемся к склайт базе, запросами берем все те данные из таблиц и нужных колонок, а потом подключаемся к посгресу и раскидываем полученные данные переменными питона в новую БД в нужные таблицы и колонки. Написал скрипт за пару часов, опробовал на тестовых БД (ну и подебажил) - работает!
Тут небольшое отступление. Все запросы в этом скрипте написаны чистым SQL, но если вам нужен будет такой скрипт на постоянку, то можно сделать более красивое решение с ОРМ, схемами и т.д. Например, сделать дамп базы и сохранить ответ не в переменную, а в файл, потом сделать восстановление БД из файла

6. Переписать существующие запросы. Ну тут логично, что после смены структуры таблиц надо переписать все запросы, которые затронуты в бэке и боте. Вот на этом этапе мы сейчас и находимся, но бэк уже переписан и работает 😎

Если интересны подробности и тонкости, то отвечу в каментах. Тут писать какой-то код и развернутые шаги не дает ограничение в символах ❤️