Хотелось для интереса написать бота на aiogram, который использует SQLAlchemy + сделать к нему админку (fastapi).
Вопрос по конфигурации уже задавался, но возник другой: как работать с БД?
В двух проектах FastAPI админ и aiogram просто будут одинаковые модели БД, обновляя в одном проекте - делаю то же самое в другом?
Или проект типа:
- bot (вся логика бота)
-- handlers
-- middleware
-- etc..
- fastapi (для админки)
-- ....
- db (SQLAlchemy модели)
-- user.py
-- product.py
-- etc
- startbot.py
- startfastapi.py
И запускать отдельно это окей?
Как правило (но это не всегда так) лучше использовать для данных общий код: модели, функции, параметры базы итд итп. Это упростит сопровождение кода, внесение изменений в структуру базы итд итп. Разные части проекта используют общий код, что уменьшает неоднозначности в поведении.
Да, это не надо воспринимать как категорическое требование. Например, если части проекта написаны на разных языках, то логично, если для них работа с базой написана на своих языках. Или если к компонентам разные требования, или они используют почти непересекающиеся части базы. Но в целом стоит очень хорошо подумать, зачем дробить работу с базой, ибо это банально неудобно и увеличивает риск ошибок и неоднозначностей.
oslik_ppc, да, примерно в таком направлении и надо мыслить. Условно, у нас есть универсальный уровень абстракции, который позволяет работать с данными и прозрачно отображать их в базу данных. И через эту прослойку работают все приложения нашего проекта. Так часто и делают.
oslik_ppc, вообще говоря, может быть не очень ок. Если код прям дублируется, то его лучше оформить как совместно используемый общий модуль. Но это, как обычно, не должно становиться самоцелью. Например, если у нас есть какая-то несложная функция на 10 строчек, которая тонет в 20 тыс. строчек непересекающегося кода обоих проектов, то усилия по выделению этого незначительного общего кода в отдельный репозиторий, подключаемый к этим проектам, могут быть совершенно неоправданы.
С другой стороны, наличие такого совпадающего микрокусочка кода может быть признаком либо того, что проекты принципиально разные и несвязанные между собой, либо что в них одни и те же вещи сделаны принципиально по-разному. И это может быть признаком архитектурно неудачных решений.
Например, в одном компоненте наворочено ORM, а в другом идёт работа многочисленными прямыми запросами к той же самой базе данных. Кода общего нет, но по факту есть две реализации работы с одной и той же базой. И внутри получаются почти такие же запросы, но разными способами и с излишним дублированием кода.
Или в одном компоненте всё построено на асинхронных вызовал async/await, а в другом - на синхронных задачах в тредпуле с коллбэками. То есть два архитектурных подхода, которые в итоге могут решать одни и те же задачи. Причём не всегда можно одно заменить другим. Например, если у нас в одном компоненте используется глубоко синхронная библиотека, то его может быть слишком сложно переделать на асинхронщину. Это, кстати, обычное узкое место рефакторинга: есть куча кода, который уже работает, но его архитектура не позволяет куски старого кода легко интегрировать в новую архитектуру.
Я раньше работал в организации, где делали собственную систему для решения различных задач, она была написана на php и восходила к разработке студента, который в начале нулевых писал код вообще без функций :) По мере усложнения было много боли по переделыванию этого всего на Zend Framework, классы, MVC и всё такое. И там прогеры как-то прилично усилий потратили, чтобы научиться корректно и без побочных эффектов вызывать из старого кода новый и наоборот, чтобы можно было рефакторить по частям, а не писать полностью идентичный аналог параллельно с поддержкой существующего.
Но если это собственный мелкий проект, затеваемый с нуля, то можно просто волевым решением выбирать изначальное единообразие, чтобы не создавать себе причин излишне страдать в будущем. Сразу стремиться к одинаковой работе с данными через единый модуль с ORM.
Средний
Простой
