5 ошибок в Django, которые ломают проект задолго до выхода в прод
Django часто берут за скорость старта, но именно на старте закладывают проблемы, которые потом больно чинить.
— Логика в views и serializers. Когда бизнес-правила размазаны по представлениям, тесты становятся хрупкими, а изменения — дорогими. Выносите правила в services, use cases или доменные методы.
— Слишком ранний уход в raw SQL. ORM закрывает большую часть задач и помогает не плодить несовместимые запросы. SQL нужен, но как точечный инструмент, а не стиль жизни.
— Модели без явных ограничений. Если уникальность, nullability и связи не зафиксированы в схеме, баги начинают жить в приложении. База должна проверять то, что может проверить сама.
— Слабая работа с миграциями. Большие миграции, переименование полей «в лоб» и удаление без этапов отката — типичный путь к простоям.
— Игнорирование индексов и запросов. Django не спасает от N+1, тяжёлых select_related/prefetch_related и фильтрации по неиндексированным полям.
Есть наблюдение которое стоит проверить: если новый разработчик не может за 10 минут понять, где у вас живёт бизнес-логика, проект уже начал усложняться.
Держите границу: модель — про данные и инварианты, сервис — про сценарий, view — про HTTP. Эта дисциплина окупается быстрее, чем кажется.
Django часто берут за скорость старта, но именно на старте закладывают проблемы, которые потом больно чинить.
— Логика в views и serializers. Когда бизнес-правила размазаны по представлениям, тесты становятся хрупкими, а изменения — дорогими. Выносите правила в services, use cases или доменные методы.
— Слишком ранний уход в raw SQL. ORM закрывает большую часть задач и помогает не плодить несовместимые запросы. SQL нужен, но как точечный инструмент, а не стиль жизни.
— Модели без явных ограничений. Если уникальность, nullability и связи не зафиксированы в схеме, баги начинают жить в приложении. База должна проверять то, что может проверить сама.
— Слабая работа с миграциями. Большие миграции, переименование полей «в лоб» и удаление без этапов отката — типичный путь к простоям.
— Игнорирование индексов и запросов. Django не спасает от N+1, тяжёлых select_related/prefetch_related и фильтрации по неиндексированным полям.
Есть наблюдение которое стоит проверить: если новый разработчик не может за 10 минут понять, где у вас живёт бизнес-логика, проект уже начал усложняться.
Держите границу: модель — про данные и инварианты, сервис — про сценарий, view — про HTTP. Эта дисциплина окупается быстрее, чем кажется.
Flask в проде ломается не из-за фреймворка, а из-за вокруг него
Flask часто выбирают за простоту, и это же потом оборачивается хаосом: приложение растёт, а границы ответственности никто не зафиксировал. Сам фреймворк маленький — поэтому архитектуру вы собираете сами.
Полезно сразу разделить:
— конфиг: отдельные классы под dev/stage/prod, без ручных правок в коде;
— app factory: чтобы тесты и фоновые задачи создавали приложение одинаково;
— extensions: инициализация через объект, а не через глобальные импорты;
— blueprints: когда модули уже не влезают в один файл;
— ошибки и логирование: единый формат, иначе отладка превращается в археологию.
Есть наблюдение которое стоит проверить: большинство проблем с Flask появляется не на уровне HTTP, а на уровне состояния. Глобальные переменные, кеши без границ, соединения, созданные «на всякий случай», — всё это работает до первого параллельного запроса или воркера.
Если проекту нужны async-эндпоинты, сложная схема валидации и много интеграций, Flask можно оставить, но обвязку придётся строить дисциплинированно. Если нужна быстая API-платформа с меньшим количеством самосбора, часто проще смотреть в сторону FastAPI или Starlette.
Правило простое: в Flask экономят не на коде, а на решениях, которые нужно принять заранее.
Flask часто выбирают за простоту, и это же потом оборачивается хаосом: приложение растёт, а границы ответственности никто не зафиксировал. Сам фреймворк маленький — поэтому архитектуру вы собираете сами.
Полезно сразу разделить:
— конфиг: отдельные классы под dev/stage/prod, без ручных правок в коде;
— app factory: чтобы тесты и фоновые задачи создавали приложение одинаково;
— extensions: инициализация через объект, а не через глобальные импорты;
— blueprints: когда модули уже не влезают в один файл;
— ошибки и логирование: единый формат, иначе отладка превращается в археологию.
Есть наблюдение которое стоит проверить: большинство проблем с Flask появляется не на уровне HTTP, а на уровне состояния. Глобальные переменные, кеши без границ, соединения, созданные «на всякий случай», — всё это работает до первого параллельного запроса или воркера.
Если проекту нужны async-эндпоинты, сложная схема валидации и много интеграций, Flask можно оставить, но обвязку придётся строить дисциплинированно. Если нужна быстая API-платформа с меньшим количеством самосбора, часто проще смотреть в сторону FastAPI или Starlette.
Правило простое: в Flask экономят не на коде, а на решениях, которые нужно принять заранее.
FastAPI ломают не роуты, а мелочи вокруг схем, зависимостей и async
FastAPI обычно стартует быстро и без боли. А потом начинаются проблемы не в коде эндпоинта, а в обвязке: валидация, зависимости, фоновые задачи, БД, сериализация.
Три места, где чаще всего ошибаются:
— смешивают sync и async без понимания, где именно блокируется event loop;
— тянут в обработчик тяжёлую логику вместо сервиса/репозитория;
— полагаются на автоматическую документацию и забывают проверять реальные схемы ответа.
Отдельно следите за pydantic-моделями. Если модель запроса и модель ответа живут одной жизнью, проект быстро начинает «подтекать»: лишние поля, неочевидные defaults, странные изменения контракта. Лучше держать DTO явными и не экономить на структуре.
Ещё одна типовая ловушка — зависимости через
Если FastAPI в проекте уже есть, проверьте три вещи: где у вас блокирующий код, насколько явны схемы API и можно ли тестировать бизнес-логику без запуска приложения. Именно там обычно находится большая часть стоимости поддержки.
FastAPI обычно стартует быстро и без боли. А потом начинаются проблемы не в коде эндпоинта, а в обвязке: валидация, зависимости, фоновые задачи, БД, сериализация.
Три места, где чаще всего ошибаются:
— смешивают sync и async без понимания, где именно блокируется event loop;
— тянут в обработчик тяжёлую логику вместо сервиса/репозитория;
— полагаются на автоматическую документацию и забывают проверять реальные схемы ответа.
Отдельно следите за pydantic-моделями. Если модель запроса и модель ответа живут одной жизнью, проект быстро начинает «подтекать»: лишние поля, неочевидные defaults, странные изменения контракта. Лучше держать DTO явными и не экономить на структуре.
Ещё одна типовая ловушка — зависимости через
Depends. Это удобно, пока в них не прячут доступ к БД, кешу, конфигу и авторизацию одновременно. Такая зависимость становится мини-фреймворком и потом плохо тестируется.Если FastAPI в проекте уже есть, проверьте три вещи: где у вас блокирующий код, насколько явны схемы API и можно ли тестировать бизнес-логику без запуска приложения. Именно там обычно находится большая часть стоимости поддержки.