Flask ломается не на роутинге, а на мелочах вокруг приложения

Flask ломается не на роутинге, а на мелочах вокруг приложения

За неделю в репах чаще всего всплывают не «сложные баги», а одни и те же промахи:
— держат глобальное состояние в модуле, а потом ловят гонки между запросами;
— тянут конфиг вручную по файлам, вместо одного объекта настроек;
— смешивают view, бизнес-логику и доступ к БД в одном обработчике.

У Flask сильная сторона — минимальный каркас. Но именно поэтому важно сразу разделить слои: route только принимает и возвращает, сервисы считают, репозитории читают и пишут. Как только логика расползается по handlers, тесты становятся дорогими, а любой рефакторинг превращается в лотерею.

Ещё одна типовая ошибка — жить на расширениях как на магии. Они удобны для auth, миграций и сессий, но если каждый пакет начинает управлять всем приложением, дебаг становится неприятным. Лучше явно собирать зависимости в фабрике приложения и передавать их туда, где они нужны. Это хорошо ложится и на unittest, и на интеграционные тесты 🧩

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