<b>Starlette ломается не на роутинге, а на мелочах вокруг ASGI</b>

<b>Starlette ломается не на роутинге, а на мелочах вокруг ASGI</b>

Starlette часто берут как «лёгкий фундамент» для API, но ошибки обычно сидят не в маршрутах, а в обвязке. Если проект начинает тормозить или вести себя странно, смотрят в middleware, работу с ответами и поток запросов, а не в сам endpoint.

Три места, где чаще всего прячется боль:
— тяжёлый middleware на каждом запросе;
— синхронный код внутри async-хендлера;
— чтение тела запроса больше одного раза без буфера.

Ещё одна типовая ловушка — смешивать ответственность. Когда endpoint одновременно валидирует, ходит в БД, форматирует ответ и пишет логи, отладка превращается в квест. В Starlette лучше держать слой маршрутизации тонким: запрос принял, данные передал, ответ вернул.

Полезный тест для любого проекта: если убрать один middleware или вынести один sync-вызов в отдельный threadpool, поведение сразу меняется — узкое место уже найдено. Это почти всегда дешевле, чем переписывать весь стек.