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

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

Starlette — это не «мини-фреймворк для старта», а очень тонкий ASGI-слой для веба и сервисов. Его сильная сторона — предсказуемый рендер запроса, middleware, роутинг, фоновые задачи и WebSocket без лишней магии.

Есть наблюдение которое стоит проверить: проблемы в проектах на Starlette обычно начинаются не в роутере, а в границах приложения.
• неявные зависимости в endpoint-функциях;
• смешивание HTTP-логики и доступа к данным;
• middleware, который меняет контекст запроса;
• ручная обработка ошибок без единого формата ответа.

Если нужен стабильный шаблон, держите простую схему: роутер только принимает и отдает, бизнес-логика живет в сервисах, доступ к БД — в отдельных слоях, а общие ошибки переводятся в один формат через exception handlers. Тогда Starlette остается тем, чем он и должен быть: транспортом, а не местом, где копится хаос.

Еще один полезный прием — не перегружать middleware. Если слой должен логировать, валидировать, ставить заголовки и еще решать, пускать ли запрос дальше, его лучше разрезать. В Starlette это особенно заметно: чем тоньше слой, тем проще отлаживать async-поведение и тесты.

Если проект на Starlette начинает «расползаться», первым делом проверьте границы слоев, а не количество роутов: архитектура тут почти всегда важнее синтаксиса.