Post Starlette часто выбирают как «легкий FastAPI», но ошибку делают в другом месте

Starlette часто выбирают как «легкий FastAPI», но ошибку делают в другом месте Starlette — это не «мини-фреймворк для старта», а очень тонкий ASGI-слой для веба и сервисов. Его сильная сторона — предсказуемый рендер запроса, middleware, роутинг, фоновые задачи и WebSocket без лишней магии. Есть наблюдение которое стоит проверить: проблемы в проектах на Starlette обычно начинаются не в роутере, а в границах приложения. • неявные зависимости в endpoint-функциях; • смешивание HTTP-логики и доступа к данным; • middleware, который меняет контекст запроса; • ручная обработка ошибок без единого формата ответа. Если нужен стабильный шаблон, держите простую схему: роутер только принимает и отдает, бизнес-логика живет в сервисах, доступ к БД — в отдельных слоях, а общие ошибки переводятся в один формат через exception handlers. Тогда Starlette остается тем, чем он и должен быть: транспортом, а не местом, где копится хаос. Еще один полезный прием — не перегружать middleware. Если слой должен логировать, валидировать, ставить заголовки и еще решать, пускать ли запрос дальше, его лучше разрезать. В Starlette это особенно заметно: чем тоньше слой, тем проще отлаживать async-поведение и тесты. Если проект на Starlette начинает «расползаться», первым делом проверьте границы слоев, а не количество роутов: архитектура тут почти всегда важнее синтаксиса.