FastAPI: Хватит писать всё в main.py. Гайд по нормальной структуре для новичков

[@Dair_Targ]

Основная проблема: fastapi - это отличная библиотека для маленьких проектов.

То, что Вы предлагаете непосредственно - фактически сделать какой-то свой фреймворк (то есть систему, которая предписывает, как что делать, куда что класть) на базе связки fastapi+sqlalchemy+alembic+.... Проблема в том, что в результате получается самописный фреймворк со всеми болезнями и недоработками самописных фреймворков.

Тогда вопрос: а почему не взять django, который является готовым фреймворком, и в котором все описанные решения уже сделали и отточили?

[@enamored_poc]

Спасибо за комментарий, вопрос отличный и закономерный.

Действительно, Django — прекрасный "батарейный" фреймворк, где многие решения приняты за разработчика. Если задача — быстро поднять стандартную админку и CRUD, Django часто выигрывает.

Однако я не соглашусь с тезисом, что FastAPI — только для маленьких проектов. Структура, которую я описываю, — это не попытка "написать свой фреймворк", а реализация классической Clean Architecture / Layered Architecture.
Мы не изобретаем велосипед, а используем принцип Composition over Inheritance (композиция вместо наследования), который лежит в основе FastAPI.

Почему не Django?

1. Асинхронность: FastAPI изначально спроектирован под async/await и высокий I/O. Django async догоняет, но тащит огромный синхронный хвост.

2. Типизация: Связка Pydantic + FastAPI дает строгую валидацию и автодокументацию на уровне типов Python. В Django работа с типами часто менее прозрачна (магия ORM).

3. SQLAlchemy 2.0: Она дает гораздо больше контроля над SQL-запросами, чем Django ORM, что критично на высоких нагрузках.

Выбор между ними — это выбор между "Convention over Configuration" (Django) и "Explicit is better than implicit" (FastAPI). Эта статья для тех, кто выбрал второй путь и хочет пройти его правильно».

[@Vindicar]

И текст статьи, и комментарий - генеративщина.

[@enamored_poc]

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

[@remzalp]

Хм, у Вас примерно по статье в день. С одной стороны здесь написаны полезные вещи, с другой стороны качественная статья так быстро не пишется

[@enamored_poc]

А вы можете сказать, что именно в этой статье некачественное, чтобы в будущих статьях я не допускал таких ошибок, заранее благодарен)

[@myhicursed]

максимально не согласен. думаю у вас недостаточно опыта в этом вопросе. сейчас подавляющее большинство проектов на fastapi делается, от малых до больших.и вся эта архитектура максимально гибкая и легко поддерживаемая. а если у вас трудности с проектированием, нужно набираться опыта. у django много своих минусов. и готовое != всегда хорошее.

[@sylotana]

Так FastAPI, это фреймворк для API слоя (остальное считай можно на чистом питоне писать), в то время как Django сразу предписывает архитектуру

[@sylotana]

В статье просто привелся самый базовый пример архитектуры, так то можно и по другому организовывать

[@Sovetkali]

Мне как новичку было полезно. Во-первых, делаю свой пет-проект и сверился с вашей статьей и понял, что делаю правильно. Тоже решил максимально разносить сущности. Во-вторых, во много мне помог chatGPT и предложил ~ такое же решение, какое вы описали. Нашел в ваших рассуждениях подтверждения, что такой подход хорошо решает мои задачи.

[@enamored_poc]

Спасибо за объективное мнение)