Publication Flask ломается не на роутинге, а на границе между приложением и скриптом

Flask ломается не на роутинге, а на границе между приложением и скриптом У Flask простая поверхность, и из-за этого его часто превращают в «файл с импортами». Потом начинается боль: конфиг читается не там, зависимости живут в глобалях, а тесты падают от случайного состояния. Если проект растёт, это почти всегда вопрос не фреймворка, а структуры. Держите три правила: — создавайте приложение через фабрику, а не в модуле с роутами; — выносите настройки в отдельный объект, без прямого чтения env в бизнес-логике; — не тяните db/session/client в глобальную область, если их можно передать явно. Для маленького сервиса Flask удобен именно тем, что в нём легко держать границу между HTTP-слоем и кодом домена. Маршрут должен принимать данные, вызывать функцию и отдавать ответ. Всё, что похоже на вычисления, парсинг, интеграции и очереди, лучше вынести в отдельные модули — тогда код можно переиспользовать и в CLI, и в воркере. Если нужен долгоживущий Flask-проект, проверяйте не «как быстро поднялся сервер», а насколько легко заменить хранилище, подменить клиент внешнего API и прогнать тесты без веб-стека. Если это делается без магии, проект будет жить спокойно.