Starlette часто берут как “лёгкий FastAPI”, а потом теряют время на базовых настройках

Starlette хорош там, где нужен тонкий контроль над ASGI: свои роуты, middleware, background tasks, WebSocket, стриминг. Но именно из-за этой свободы ошибки всплывают быстро — особенно если проект растёт из одного сервиса в несколько.

Что проверять сразу:
— не тащить тяжёлую логику в endpoint: вынесите её в сервисы и фоновые задачи
— явно настраивать middleware: порядок важен, особенно для CORS, сессий и логирования
— для длинных ответов использовать StreamingResponse, а не собирать всё в память
— не смешивать WebSocket и обычный HTTP в одной “куче” кода без слоя абстракции

Отдельно следите за обработкой ошибок. В Starlette удобно повесить свой exception handler, но если он молча глотает детали, отладка превращается в квест. Лучше возвращать единый формат ответа и отдельно логировать контекст запроса.

Ещё одна типовая ловушка — тесты. Если приложение собирается из middleware, dependency-like функций и фоновых задач, проверяйте не только код ответа, но и побочные эффекты: заголовки, записи в лог, запуск задач, закрытие соединений.

Если нужен минимальный ASGI-слой без магии — Starlette отличный выбор. Но его сила раскрывается только тогда, когда архитектура остаётся явной: где запрос обрабатывается, где живёт бизнес-логика, и что именно делает middleware.