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

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

Чаще всего проект начинает “тормозить” не из-за самого фреймворка, а из-за того, как в нём собирают сервисный слой. Если зависимость тянет БД, кэш и внешний API в одном вызове, тестировать и отлаживать это почти невозможно.

Держите базовый чек-лист:
— разделяйте endpoint, service и repository;
— выносите I/O в отдельные функции, а не в обработчик;
— для входа и выхода используйте pydantic-схемы, а не сырые dict;
— не смешивайте бизнес-логику с зависимостями через Depends, если это можно передать явно.

Ещё одна частая ошибка — считать, что async везде ускорит код. Если внутри синхронный драйвер, тяжёлый JSON или блокирующий SDK, event loop всё равно будет ждать. В таком месте лучше честно оставить sync-участок или вынести его в отдельный worker.

И последнее: держите OpenAPI и схемы ответа в порядке. Когда контракт не совпадает с реальным payload, интеграции ломаются тихо, а поиск причины занимает больше всего времени. Хороший FastAPI-проект читается не по количеству эндпоинтов, а по тому, насколько предсказуемо в нём проходят данные.