5 ошибок в Django, которые ломают проект задолго до выхода в прод

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 экономят не на коде, а на решениях, которые нужно принять заранее.

FastAPI ломают не роуты, а мелочи вокруг схем, зависимостей и async

FastAPI обычно стартует быстро и без боли. А потом начинаются проблемы не в коде эндпоинта, а в обвязке: валидация, зависимости, фоновые задачи, БД, сериализация.

Три места, где чаще всего ошибаются:
— смешивают sync и async без понимания, где именно блокируется event loop;
— тянут в обработчик тяжёлую логику вместо сервиса/репозитория;
— полагаются на автоматическую документацию и забывают проверять реальные схемы ответа.

Отдельно следите за pydantic-моделями. Если модель запроса и модель ответа живут одной жизнью, проект быстро начинает «подтекать»: лишние поля, неочевидные defaults, странные изменения контракта. Лучше держать DTO явными и не экономить на структуре.

Ещё одна типовая ловушка — зависимости через Depends. Это удобно, пока в них не прячут доступ к БД, кешу, конфигу и авторизацию одновременно. Такая зависимость становится мини-фреймворком и потом плохо тестируется.

Если FastAPI в проекте уже есть, проверьте три вещи: где у вас блокирующий код, насколько явны схемы API и можно ли тестировать бизнес-логику без запуска приложения. Именно там обычно находится большая часть стоимости поддержки.

ChatGPT даёт в 190 раз меньше переходов, но уже ломает привычный SEO-учёт

Ahrefs за полгода проанализировал миллиард точек данных: 28.3% страниц, которые ChatGPT цитирует снова и снова, в Google вообще не видны. При этом 43.8% всех цитат ChatGPT — топы и списки.

Для веб-команд это не повод переписывать весь контент под LLM. Но повод отделить «видимость в Google» от «цитируемости в ChatGPT» в аналитике. Завтра можно поднять простой Python-скрипт по логам/nginx/GA export: отдельно считать рефералы Google и ChatGPT, типы страниц, шаблоны URL и конверсию по ним.

Schema-разметка по этим данным не дала заметного эффекта для AI Overviews, AI Mode и ChatGPT. Значит, автоматизировать стоит не массовую разметку, а инвентаризацию страниц: топы, списки, сравнения, evergreen-гайды и их фактический трафик.

CPM в Facebook вырос на 12–18%, а креатив живёт 3–5 дней

В арбитраже 2024 окончательно стал Creative-First: при активном спенде средний срок жизни креатива сократился до 3–5 дней. В Tier-1 более 60% объявлений уже используют UGC или AI-графику.

Для Python-разработчика это не «заказать ещё баннер», а задача на конвейер: хранить гипотезы, генерировать вариации, проставлять UTM, резать видео, вести статусы модерации и быстро отдавать связки баеру.

Минимальный завтрашний слой: FastAPI-админка + Celery-воркеры для рендера/нарезки + таблица результатов по GEO и офферу. Когда креатив сгорает за неделю, ручной хаос начинает стоить дороже самого продакшена.

Вопрос не в том, делать ли автоматизацию. Вопрос — кто в команде первым перестанет переименовывать файлы руками.