FastAPI ломается не на роутинге, а на границах данных и зависимостей

FastAPI ломается не на роутинге, а на границах данных и зависимостей

В проектах на FastAPI чаще всего проблемы прячутся не в эндпоинтах, а в том, что вокруг них: схемы, DI, фоновые задачи, подключение БД. Если оставить это «на потом», API ещё отвечает, но уже живёт на допусках и костылях.

Три места, которые надо жёстко дисциплинировать:
— входные модели: не пускайте в обработчик «сырой» dict, только pydantic-схемы;
— зависимости: всё, что открывает соединение или читает конфиг, должно быть в одном слое;
— ошибки: единый формат ответа важнее, чем десяток `raise HTTPException` в каждом файле.

Ещё одна типовая ошибка — смешивать бизнес-логику с endpoint-функцией. Когда в `router` лежат и валидация, и SQL, и отправка письма, тесты становятся дорогими, а рефакторинг опасным. Лучше держать обработчик тонким: принял данные, вызвал сервис, вернул ответ.

Если нужен API, который не развалится после пары расширений, проектируйте границы заранее: схема на входе, сервис в середине, адаптеры снаружи. Тогда FastAPI остаётся быстрым, а не просто удобным для старта.