FastAPI или Django: что я выбрал для двух своих продакшенов и почему

Этот вопрос мне задают ученики курса примерно на второй неделе: «На чём писать бэкенд?» Обычно ждут ответа про производительность и бенчмарки. А решает совсем другое.

Расскажу не теорию, а свою ситуацию. У меня два живых продакшена. ПКМаркетинг — SaaS для автоматизации маркетинга: 13 000+ пользователей, государственная IT-аккредитация, стек Next.js, FastAPI, PostgreSQL, Docker, Redis, Celery. И therebro.ru — сайт, на котором ты сейчас читаешь: тот же Next.js, FastAPI, PostgreSQL, Docker, плюс личный кабинет с курсом, уроками, домашками и приёмом оплат.

Оба на FastAPI. Это не идеология, это стечение конкретных обстоятельств. Разберём каких.

Почему у меня FastAPI

Бэкенд отдельно от фронтенда. Оба проекта — Next.js спереди и API сзади. Django в такой схеме работает как REST-сервер, но половина его силы — шаблоны, формы, встроенные страницы — просто не используется. Ты платишь весом за то, к чему не притрагиваешься.

Валидация на границе системы. Pydantic-схема — это описание того, что вообще имеет право войти внутрь приложения. Тип, длина, формат, обязательность. Всё, что не проходит, отваливается на входе с внятной ошибкой, а не где-то в глубине бизнес-логики. Для проекта, где есть публичные формы и приём платежей, это не украшение, а базовая безопасность.

Асинхронность как норма. ПКМаркетинг постоянно ходит наружу: API соцсетей, нейросети, вебхуки CRM. Когда рассылка уходит со скоростью 38 000 сообщений за 2 минуты 45 секунд, а парсер обрабатывает 15 миллионов сообществ в день, узкое место — не вычисления, а ожидание чужих ответов. Async тут не роскошь.

Живая документация. FastAPI сам собирает описание всех эндпоинтов из кода. Это экономит время, когда фронтенд пишется параллельно с бэкендом, и особенно — когда его пишет AI-агент.

Чем за это приходится платить

Честно, без рекламы. FastAPI — не «фреймворк со всем внутри». Он даёт вам роутинг и валидацию, остальное вы приносите сами:

• Админки нет. В Django она из коробки, здесь её пишешь руками. На therebro.ru админка — это отдельный раздел на фронтенде плюс защищённые эндпоинты. Это дни работы.
• ORM нет. Ставишь SQLAlchemy и настраиваешь сам, включая асинхронные сессии.
• Миграции нет. Отдельный инструмент, отдельная дисциплина.
• Авторизации нет. Токены, роли, хеширование паролей, разграничение доступа — всё пишется под проект.

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

Когда я советую Django

Не всегда я выбираю FastAPI. Django выигрывает в понятных ситуациях:

• Нужна админка вчера. Контент-проект, где редакторы должны править записи, — Django даёт это почти бесплатно.
• Классический сайт с серверным рендерингом. Если фронтенд не отдельное приложение, а страницы из шаблонов.
• Интернет-магазин на готовых решениях. Экосистема Django накопила пакеты под большинство типовых задач ecommerce.
• Команда без опыта async. Асинхронный код прощает меньше ошибок. Если разработчики не понимают, чем блокирующий вызов опасен внутри корутины, Django даст более предсказуемый результат.

Формула простая: чем ближе проект к «сайт с контентом и админкой», тем сильнее Django. Чем ближе к «API для приложения, ботов и интеграций», тем сильнее FastAPI.

А что удобнее для вайбкодинга

Это уже мой личный угол зрения — с ним не все согласятся.

AI-агент пишет тем лучше, чем меньше в проекте неявной магии. FastAPI явный до занудства: у эндпоинта видны типы аргументов, схема запроса, схема ответа, зависимости. Агент читает это как чертёж и почти не додумывает. Ошибки, если они есть, всплывают сразу — на валидации или на типах.

В Django многое держится на соглашениях: где лежит файл, как называется класс, что подхватится автоматически. Человек эти соглашения знает, а агент иногда смешивает подходы из разных версий фреймворка, и результат выглядит правдоподобно, но не работает. Лечится это правилами проекта — файлом договорённостей, который агент читает перед работой, — но лечить приходится.

Так что если ты только заходишь в разработку через вайбкодинг, FastAPI даст более честную обратную связь. Он не позволит долго не понимать, что происходит.

Четыре вопроса, чтобы выбрать за десять минут

1. Фронтенд отдельный? Да — FastAPI. Нет, страницы рендерит бэкенд — Django.
2. Нужна админка для нетехнических людей? Да — Django сильно впереди.
3. Много внешних интеграций и долгих запросов наружу? Да — FastAPI.
4. Кто будет это поддерживать через год? Если команда живёт в Django — не геройствуйте, берите Django. Незнакомый стек стоит дороже любых миллисекунд.

Чего в этом списке нет — так это вопроса «что быстрее». На реальных проектах бэкенд почти никогда не оказывается узким местом: тормозят чужие API, база и неоптимальные запросы. Выбирать фреймворк по бенчмаркам — самый простой способ ошибиться.

Вывод

FastAPI я беру, когда делаю API: сервисы, боты, интеграции, платформы с отдельным фронтендом. Django — когда делаю сайт с контентом, редакторами и админкой. Оба варианта — нормальные инженерные решения, и оба переживут ваш проект.

А главное: с AI-агентом ты можешь позволить себе разобраться в обоих. Раньше на освоение фреймворка уходили месяцы. Сейчас — вечер на прототип и понимание, ложится ли инструмент на задачу.

Хочешь собирать такое сам?

На курсе по вайбкодингу я веду один на один: разбираем архитектуру, ставим задачи агенту, доводим до работающего проекта в продакшене — 6 модулей, 42 урока, больше 80 выпускников. Именно так собраны и ПКМаркетинг, и платформа, на которой ты читаешь эту статью.

Посмотри программу курса или напиши мне — разберём, что ты хочешь построить, и с чего начать. Быстрее всего отвечаю в Telegram: t.me/therebro.