Потому волюм в docker-compose и так прокидывает эту директорию в контейнер. Docker compose не всегда нужен только для локальной разработки. Например, с его помощью можно накатывать ПО для заказчиков и не возиться с особенностями установленной у него операционки

Ver_P Dec 31 2024 at 16:04

А не проще использовать готовые шаблоны, например Cookiecutter? Для Джанго приложений полностью на него перешёл - удобно и быстро, только надо разобраться в структуре проекта)

max31ru12 Dec 31 2024 at 16:56

В зависимости от того, что вам нужно. Шаблон Cookiecutter для fastapi содержит в себе очень много всего, не всегда столько нужно для простого api. Да и кажется его больше не поддерживают (последнее обновление 4 года назад)

VPryadchenko Dec 31 2024 at 17:21

Есть вот вроде от самого fastapi: https://github.com/fastapi/full-stack-fastapi-template

Pubert Dec 31 2024 at 19:31

На всякий случай - uvicorn с опцией --reload потребляет очень много ресурсов и может тормозить, о чём говорится прям в документации) поэтому использовать на проде крайне не рекомендуется (можно в том случае, если ресурсов предостаточно, или высокая производительность не требуется)

roslovets Dec 31 2024 at 20:42

А SQLModel пробовали? Он объединяет Sqlalchemy с Pydantic. В моих проектах на fastapi хорошо заходит, но бывают некоторые неудобства из-за абстракции поверх алхимии.

max31ru12 Jan 1 at 05:43

Пока не пробовал. Наверное, стоит попробовать. Есть либа, которая позволяет маппить модели sqlalchemy в модели pydantic. Называется pydantic-marshals, тоже довольно удобная вещь

roslovets Dec 31 2024 at 20:44

И ещё вопрос, почему requirements.txt, а не pyproject.toml, где можно гибко управлять зависимостями?

max31ru12 Jan 1 at 05:45

Потому что это самый простой вариант. Его всегда можно легко и просто заменить на pyproject.toml, при желании

iantoshkai Jan 2 at 15:03

вместо pip советую uv

max31ru12 Jan 2 at 15:03

Спасибо, посмотрю!

gyolkin Jan 2 at 15:04

Мне кажется, в тексте не хватает двух слов о существующих шаблонах "FastAPI приложений", которых на GitHub действительно много. Например, full-stack-fastapi-template от tiangolo, создателя этого фреймворка. Мотивация автора понятна, но совсем не понятно, почему не решили использовать один из существующих шаблонов? Что в этом шаблоне есть такого, чего нет в уже существующих?

Также хочу отметить, что вы лишаете свое приложение гибкости и масштабируемости, используя подобную структуру. FastAPI - это микрофреймворк. Легкий инструмент, чтобы принимать запросы, передавать полученную информацию куда-то еще, возвращать ответ пользователю. Веб-фреймворк принадлежит к "внешнему кругу", если выражаться в терминах чистой архитектуры, и это неспроста. Роль FastAPI в приложении весьма примитивна и ограниченна, однако в такой структуре он стоит в центре, что подтверждает и автор статьи:

все эти папки (за исключение, наверное, api/) опциональны...

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

max31ru12 Jan 2 at 15:29

Спасибо за конструктивный комментарий, постараюсь так же конструктивно ответить.

Я не упоминал о существующих шаблонах, по нескольким причинам:
1) Я с ними слабо знаком и не использую их (хотя я понимаю, что стоит ознакомиться)
2) Они часто имеют избыточный функционал (как пример, cookiecutter содержит в себе фронт на Vue, а зачем он мне нужен, если я пишу простые CRUD'ы просто чтобы попрактиковаться)

Насчет гибкости и масштабируемости хотел бы узнать более подробно. Почему моя структура плоха? Не могли бы еще привести пример проблем моего подхода с разрастанием кодовой базы? Это позволило бы мне пересмотреть свой подход и улучшить его.

QSaveSu Jan 3 at 17:11

Я только начал пытаться, было интересно почитать