> С какими Python фреймворками кроме Django вы работали? (Python)

Короткий ответ

Помимо Django, работал с FastAPI, Flask и Aiohttp. FastAPI использовал для высоконагруженных async-сервисов и микросервисной архитектуры, Flask - для небольших внутренних инструментов и прототипов, Aiohttp - для проектов с интенсивным websocket-взаимодействием. Также знаком с Starlette как основой FastAPI и Sanic в pet-проектах.

Подробное объяснение

Каждый фреймворк выбирался под конкретную задачу:

• FastAPI - основной выбор для новых сервисов: автоматическая генерация OpenAPI-спецификации, Pydantic-валидация, нативная поддержка async/await, dependency injection. Использовал в продакшене для REST API с нагрузкой до 10k RPS.
• Flask - применял для legacy-проектов и быстрых прототипов, где не нужна сложная структура. Хорошо подходит для монолитных приложений с простым роутингом.
• Aiohttp - использовал для сервисов реального времени: чаты, биржевые стримы, где критичен websocket и длинные соединения.
• Starlette - как middleware-прослойку и для понимания внутренностей FastAPI.

Ключевое отличие от Django - отсутствие "батареек": ORM, админки, миграций. Приходится самостоятельно собирать стек: SQLAlchemy или asyncpg, Alembic, Pydantic, Redis. Это даёт гибкость, но требует больше инженерной дисциплины.

На практике

В коммерческой разработке чаще всего использовал связку FastAPI + SQLAlchemy async + Alembic + Pydantic. Для фоновых задач - Celery или arq. Для тестирования - pytest + httpx. В одном из проектов мигрировал монолит на Django на FastAPI-микросервисы: выиграли в скорости разработки за счёт автодокументации и типизации, но потеряли в готовых решениях - пришлось писать свою админку и систему прав.

С Flask работал на поддержке внутреннего сервиса аналитики: там важна была простота и минимальное количество зависимостей. Aiohttp использовал для gateway-сервиса, агрегирующего данные с нескольких источников по websocket.

Пример кода

PYTHON
# Пример типичного FastAPI-эндпоинта с dependency injection
from fastapi import FastAPI, Depends, HTTPException
from pydantic import BaseModel
from sqlalchemy.ext.asyncio import AsyncSession

app = FastAPI()

class UserCreate(BaseModel):
    email: str
    name: str

async def get_db() -> AsyncSession:
    async with async_session() as session:
        yield session

@app.post("/users", status_code=201)
async def create_user(
    payload: UserCreate,
    db: AsyncSession = Depends(get_db)
):
    # валидация и сохранение
    return {"id": 1, **payload.model_dump()}

Как отвечать на собеседовании

Структурируйте ответ по принципу "фреймворк - сценарий использования - конкретный проект". Назовите 2-3 фреймворка, а не весь список. Для каждого укажите: где применяли, почему выбрали именно его, какие были ограничения. Подчеркните, что выбор фреймворка - это инженерное решение, а не предпочтение. Если спрашивают про сравнение с Django - говорите о trade-off: скорость разработки против контроля над архитектурой.

Что проверяет интервьюер

• Реальный опыт, а не теоретическое знание - просят примеры проектов и задач.
• Понимание сильных и слабых сторон фреймворков, умение обосновать выбор.
• Знание экосистемы: ORM, миграции, тестирование, деплой.
• Понимание async-модели и её отличий от синхронной.
• Способность адаптироваться к разным стекам, а не быть "только Django-разработчиком".

Типичные ошибки

• Перечисление всех фреймворков без конкретики - выглядит как поверхностное знакомство.
• Критика Django без аргументов - лучше говорить о trade-off, а не о "лучше/хуже".
• Упоминание фреймворков, с которыми нет реального опыта - интервьюер быстро проверит глубину.
• Игнорирование экосистемы: если сказали FastAPI, но не знаете Pydantic или SQLAlchemy async - это красный флаг.
• Отсутствие примеров из практики: "писал API" без деталей о нагрузке, архитектуре, проблемах.