🌶️ Flask

Короткий ответ Данные кладут в объект flask.g, который привязан к текущему request context и автоматически пересоздаётся для каждого нового запроса — это потокобезопасно, так как каждый поток/greenlet обрабатывает свой собственный контекст. Как это работает подробнее Flask использует механизм контекстных локальных переменных (context locals, основанных на werkzeug.local/contextvars), который хранит отдельный g для каждого активного request context. Даже если сервер обрабатывает несколько запросов параллельно в разных потоках, каждый поток видит «свой» g, а не общий для всех. Пример кода Что использовать на практике Практика. before_request обычно используют для подготовки данных, нужных нескольким view (например, текущий пользователь из токена), и сохраняют результат в g.current_user; после обработки запроса g автоматически уничтожается, так что данные не «утекают» в следующий запрос. Подводные камни Риск. Пытаются хранить в g данные, которые должны жить дольше одного запроса (например, кэш между запросами) —

Читать полностьюenvironment-variables

Короткий ответ Функция jsonify() формирует тело ответа в формате JSON, а статус-код задаётся как второй элемент кортежа, возвращаемого из view-функции, либо через make_response. Как это работает подробнее Flask позволяет view-функции возвращать не только строку/словарь, но и кортеж (тело, статус) или (тело, статус, заголовки). jsonify() сериализует Python-объект в JSON и устанавливает правильный Content-Type. Пример кода Что использовать на практике Практика. Для кодов ошибок (400, 404, 409 и т. п.) удобно возвращать jsonify({...}), код. Если нужно также выставить заголовки, используют make_response(jsonify(...), код) и дальше .headers[...] = .... Подводные камни Риск. Возвращают только jsonify(data) без статуса для ошибок, из-за чего клиент получает 200 даже при логической ошибке; путают abort(404) (сразу прерывает обработку и генерирует HTML/JSON ошибку через error handler) с обычным возвратом кортежа.

Читать полностьюflask

Короткий ответ Нужно явно проверить обязательные поля перед использованием данных и вернуть 400 Bad Request с понятным сообщением, либо использовать библиотеку валидации (например, marshmallow/pydantic) и перехватывать её ошибку. Как это работает подробнее Flask сам не валидирует входные данные — это задача разработчика или сторонней библиотеки. Без проверки обращение к отсутствующему ключу словаря (data['field']) вызывает KeyError, который без обработки превращается в 500 Internal Server Error, хотя по сути это ошибка клиента. Пример кода Что использовать на практике Практика. Базовый вариант — ручная проверка if 'field' not in data: return {'error': ...}, 400. Для более сложных схем применяют marshmallow/pydantic с перехватом исключения валидации и преобразованием его в 400 с деталями по полям. Подводные камни Риск. Оставляют необработанные KeyError/ValueError долетать до стандартного обработчика ошибок Flask, который в production отдаёт общий 500 без подсказки клиенту, что он прислал; не пишут отдельный те

Читать полностьюflask

Короткий ответ WSGI-middleware оборачивает сам вызываемый объект app.wsgi_app, получая доступ к «сырому» WSGI-окружению до того, как Flask начнёт маршрутизацию и построит объект request; before_request/after_request работают уже внутри контекста запроса Flask и имеют доступ к высокоуровневым объектам фреймворка. Как это работает подробнее WSGI-приложение — это просто вызываемый объект (environ, start_response) -> iterable. Оборачивая app.wsgi_app в свою функцию/класс, можно модифицировать environ до того, как Flask его обработает, или обернуть ответ на самом низком уровне — это универсально и работает с любым WSGI-совместимым фреймворком, не только Flask. Пример кода Что использовать на практике Практика. WSGI middleware обычно используют для инфраструктурных задач независимо от фреймворка (например, проксирование заголовков от балансировщика, сжатие gzip через стороннюю библиотеку, базовая авторизация на уровне инфраструктуры). before_request/after_request удобнее для логики, завязанной на Flask-специфичные

Читать полностьюflask

Короткий ответ В декораторе @app.route указывается список допустимых методов через параметр methods, а внутри функции-обработчика ветвление делается по request.method. Как это работает подробнее Flask по умолчанию регистрирует маршрут только на GET (и HEAD/OPTIONS автоматически). Чтобы разрешить другие методы, их явно перечисляют в methods=[...]. Внутри обработчика доступен текущий метод через request.method. Пример кода Что использовать на практике Практика. Для простых случаев один обработчик с условием на request.method читается нормально; если логика веток сильно различается и растёт, лучше разделить на отдельные функции или использовать MethodView. Подводные камни Риск. Забывают добавить POST в methods, из-за чего Flask возвращает 405 Method Not Allowed; путают request.form (данные формы) и request.get_json() (JSON-тело).

Читать полностьюflask

Короткий ответ Query-параметры доступны через объект flask.request.args, который ведёт себя как словарь с методом .get(), позволяющим указать значение по умолчанию и тип. Как это работает подробнее Flask парсит строку запроса (query string) из URL и складывает пары ключ-значение в request.args — объект MultiDict. Значения всегда приходят как строки, если не указать преобразование. Пример кода Что использовать на практике Практика. Для чтения с преобразованием типа и значением по умолчанию удобно использовать request.args.get('page', 1, type=int). Если параметр может повторяться (например, несколько тегов), используют request.args.getlist('tag'). Подводные камни Риск. Обращение к несуществующему параметру через request.args['page'] вызывает 400 Bad Request (KeyError оборачивается Flask), вместо аккуратного .get() с дефолтом; забывают, что значения — строки, и сравнивают строку '2' с числом 2 без преобразования.

Читать полностьюflask

Короткий ответ Общую проверку выносят в переиспользуемую функцию/декоратор и подключают её через before_request конкретного Blueprint (bp.before_request) или через общий механизм на уровне приложения с проверкой request.blueprint, избегая копирования одинаковой проверки в каждый модуль. Как это работает подробнее У каждого Blueprint есть собственные хуки before_request/after_request, которые срабатывают только для маршрутов этого Blueprint, в отличие от app.before_request, который срабатывает для всех запросов. Это позволяет применить, например, проверку авторизации только к admin-Blueprint, не трогая публичные маршруты. Пример кода Что использовать на практике Практика. Для действительно общей логики (например, добавление request_id для логирования) используют app.before_request; для логики, специфичной для группы маршрутов (авторизация только для /admin/*), — bp.before_request конкретного Blueprint. Декораторы на отдельные view оставляют для точечных исключений внутри Blueprint. Подводные камни Риск. Копиру

Читать полностьюblueprints

Короткий ответ Значения читаются через os.environ/os.getenv (опционально с библиотекой python-dotenv для локальной разработки) и затем помещаются в app.config, а не хардкодятся в исходном коде. Как это работает подробнее os.getenv('KEY', default) возвращает значение переменной окружения процесса или значение по умолчанию. Flask хранит конфигурацию приложения в словаре-подобном объекте app.config, куда удобно один раз сложить все настройки при создании приложения. Пример кода Что использовать на практике Практика. Для локальной разработки переменные окружения часто кладут в файл .env и загружают через load_dotenv() до чтения os.getenv; в production переменные задаются средствами окружения (Docker, systemd, CI/CD), и .env-файл туда не попадает. Подводные камни Риск. Хранят секреты (пароли, ключи) прямо в коде или в .env, закоммиченном в git; не задают значения по умолчанию для необязательных настроек и получают None там, где ожидалась строка.

Читать полностьюconfiguration

Короткий ответ Приложение создаётся внутри функции create_app(config=None), которая настраивает app.config, инициализирует расширения и регистрирует Blueprint, возвращая готовый объект Flask; это позволяет создавать несколько независимо сконфигурированных экземпляров приложения, например для тестов и production. Как это работает подробнее Вместо создания глобального app = Flask(__name__) на уровне модуля, который неявно захватывает конфигурацию в момент импорта, всё инкапсулируется в функцию. Тесты и разные среды вызывают create_app(test_config) с нужными настройками, получая изолированный экземпляр. Пример кода Что использовать на практике Практика. Это особенно важно для расширений типа Flask-SQLAlchemy — в тестах можно передать отдельную тестовую БД (например, SQLite in-memory) без влияния на production-конфигурацию, и создавать несколько приложений в одном процессе (например, для параллельных тестов) без конфликтов глобального состояния. Подводные камни Риск. Инициализируют расширения (db = SQLAlchemy(app

Читать полностьюblueprints