Пост FastAPI ломается не на роутинге, а на неявных зависимостях и типах

FastAPI ломается не на роутинге, а на неявных зависимостях и типах Чаще всего проект начинает “тормозить” не из-за самого фреймворка, а из-за того, как в нём собирают сервисный слой. Если зависимость тянет БД, кэш и внешний API в одном вызове, тестировать и отлаживать это почти невозможно. Держите базовый чек-лист: — разделяйте endpoint, service и repository; — выносите I/O в отдельные функции, а не в обработчик; — для входа и выхода используйте pydantic-схемы, а не сырые dict; — не смешивайте бизнес-логику с зависимостями через Depends, если это можно передать явно. Ещё одна частая ошибка — считать, что async везде ускорит код. Если внутри синхронный драйвер, тяжёлый JSON или блокирующий SDK, event loop всё равно будет ждать. В таком месте лучше честно оставить sync-участок или вынести его в отдельный worker. И последнее: держите OpenAPI и схемы ответа в порядке. Когда контракт не совпадает с реальным payload, интеграции ломаются тихо, а поиск причины занимает больше всего времени. Хороший FastAPI-проект читается не по количеству эндпоинтов, а по тому, насколько предсказуемо в нём проходят данные.