Расскажите про опыт с веб-фреймворками Django и FastAPI
Что проверяют
Понимаете ли вы, что это каркасы под разные задачи, и умеете ли обосновать выбор.
Как отвечать
Сначала различие по назначению, это главное.
Django это каркас с батарейками: своя ORM, миграции, админка, аутентификация и права, шаблоны, формы, кэш. Он навязывает структуру, и это его сила: типовое приложение собирается быстро и одинаково у всех. Синхронный по природе, хотя асинхронные представления появились.
FastAPI это микрокаркас для API. Асинхронный, построен на подсказках типов: из аннотаций получается и валидация через Pydantic, и автоматическое описание OpenAPI, и подсказки в редакторе. Ничего не навязывает: работа с базой, миграции и аутентификация подключаются самостоятельно, обычно SQLAlchemy и Alembic.
Когда что:
- Django если нужна админка, есть предметная модель со связями, много типовой работы с формами и правами, а нагрузка обычная. Экономия времени огромна;
- FastAPI если это чистый API, важна асинхронность из-за большого числа одновременных обращений к внешним сервисам, нужна строгая схема запросов и ответов.
Что рассказать по каждому из своего опыта:
- по Django: как боролись с проблемой N+1, как настраивали окружения, что выносили в фоновые задачи, как решали разрастание моделей;
- по FastAPI: как организовали внедрение зависимостей, как разделили схемы запроса, ответа и модели базы, как не заблокировали цикл событий синхронным драйвером.
Последний пункт стоит подчеркнуть: один синхронный вызов внутри асинхронного обработчика останавливает весь сервис. Это самая частая ошибка при переходе на FastAPI, и о ней полезно упомянуть самому.
Где спотыкаются
Сравнивают каркасы по скорости, а не по назначению.
Берут микрокаркас и заново пишут админку и права.
Используют синхронный драйвер базы в асинхронном обработчике.
Не могут объяснить, зачем нужны отдельные схемы для запроса и ответа.