Post Starlette ломают не роуты, а мелкие ошибки в асинхронной обвязке

Starlette ломают не роуты, а мелкие ошибки в асинхронной обвязке Starlette любят за минимализм: ASGI, middleware, роутинг, фоновые задачи — без лишней магии. Но на практике проект чаще всего тормозит не фреймворк, а то, как в нём пишут обработчики и подключают зависимости. Проверьте базу: — в async-endpoint не вызывайте тяжёлый sync-код напрямую, иначе блокируете event loop; — для CPU-bound и долгих I/O выносите работу в отдельные процессы или очереди; — middleware держите короткими: каждый лишний шаг проходит через весь запрос; — не плодите глобальное состояние, если приложение масштабируется в несколько воркеров. Ещё одна типовая ошибка — смешивать быстрый API и тяжёлую бизнес-логику в одном слое. Starlette хорошо подходит как тонкий HTTP-слой, а сложные сценарии лучше уводить в сервисы, фоновые задачи или отдельные модули. Так проще тестировать, менять транспорт и не тащить веб-детали в доменную часть. Если нужен каркас без лишнего шума, Starlette берут именно за это: ясный поток запроса, предсказуемая асинхронность и минимум скрытого поведения. Начните с чистых handlers, затем отдельно проверьте middleware, блокировки и точки, где sync-код случайно попал в async-путь.