Структура и жизненный цикл приложения

Настройка приложения

Первый шаг в создании приложения Flask — создание объекта приложения. Каждое приложение Flask — это экземпляр класса Flask, который собирает всю конфигурацию, расширения и представления.

from flask import Flask

app = Flask(__name__)
app.config.from_mapping(
    SECRET_KEY="dev",
)
app.config.from_prefixed_env()

@app.route("/")
def index():
    return "Hello, World!"

Это известно как «фаза настройки приложения»; это код, который вы пишете вне функций представлений или других обработчиков. Он может быть разделен между различными модулями и подпакетами, но весь код, который вы хотите включить в свое приложение, должен быть импортирован для регистрации.

Вся настройка приложения должна быть завершена перед запуском приложения и обработкой запросов. Это связано с тем, что серверы WSGI распределяют работу между несколькими рабочими процессами или могут быть распределены по нескольким машинам. Если конфигурация изменится в одном рабочем процессе, Flask не сможет гарантировать согласованность между другими рабочими процессами.

Flask пытается помочь разработчикам обнаруживать некоторые из этих проблем с порядком настройки, показывая ошибку, если методы, связанные с настройкой, вызываются после обработки запросов. В этом случае вы увидите следующую ошибку:

Метод настройки «route» больше не может быть вызван для приложения. Оно уже обработало свой первый запрос, любые изменения не будут применены согласованно. Убедитесь, что все импорты, декораторы, функции и т. д., необходимые для настройки приложения, выполнены до его запуска.

Однако Flask не может обнаружить все случаи несоответствующей настройки. В общем, не делайте ничего, чтобы изменить объект приложения Flask и объекты Blueprint из функций представлений, которые выполняются во время запросов. Это включает:

• Добавление маршрутов, функций представлений и других обработчиков запросов с помощью @app.route, @app.errorhandler, @app.before_request, и т. д.
• Регистрация планов.
• Загрузка конфигурации с помощью app.config.
• Настройка среды шаблонов Jinja с помощью app.jinja_env.
• Установка интерфейса сессий вместо стандартных cookie itsdangerous.
• Установка поставщика JSON с помощью app.json, вместо стандартного поставщика.
• Создание и инициализация расширений Flask.

Обслуживание приложения

Flask — это фреймворк приложений WSGI. Другая половина WSGI — это сервер WSGI. Во время разработки Flask через Werkzeug предоставляет сервер WSGI разработки с помощью команды flask run CLI. Когда вы закончите с разработкой, используйте сервер производства для обслуживания вашего приложения, см. Развертывание в производство.

Независимо от используемого сервера, он будет следовать спецификации WSGI PEP 3333. Сервер WSGI получит информацию о том, как получить доступ к вашему объекту приложения Flask, который является приложением WSGI. Затем он начнет прослушивать HTTP-запросы, преобразовывать данные запроса в WSGI environ и вызывать приложение WSGI с этими данными. Приложение WSGI вернет данные, которые будут преобразованы в HTTP-ответ.

1. Браузер или другой клиент отправляет HTTP-запрос.
2. Сервер WSGI получает запрос.
3. Сервер WSGI преобразует данные HTTP в словарь WSGI environ.
4. Сервер WSGI вызывает приложение WSGI с данным environ.
5. Flask, приложение WSGI, выполняет всю свою внутреннюю обработку для маршрутизации запроса к функции представления, обработки ошибок и т. д.
6. Flask преобразует возвращаемое значение функции представления в данные WSGI-ответа и передает их серверу WSGI.
7. Сервер WSGI создает и отправляет HTTP-ответ.
8. Клиент получает HTTP-ответ.

Как обрабатывается запрос

Для нас интересной частью вышеперечисленных шагов является момент, когда сервер WSGI (или middleware) вызывает Flask. В этот момент он выполняет довольно много действий для обработки запроса и генерации ответа. В самом простом случае он сопоставит URL с функцией-представлением, вызовет эту функцию и передаст возвращаемое значение обратно серверу. Но есть множество других возможностей для настройки его поведения.

1. Сервер WSGI вызывает объект Flask, который вызывает Flask.wsgi_app().
2. Создается объект RequestContext. Он преобразует словарь WSGI environ в объект Request. Он также создает объект AppContext.
3. Контекст приложения контекст приложения подталкивается, что делает доступными current_app и g.
4. Отправляется сигнал appcontext_pushed.
5. Подталкивается контекст запроса контекст запроса, что делает доступными request и session.
6. Сессия открывается, загружая любые существующие данные сессии с использованием интерфейса сессии приложения session_interface, экземпляра SessionInterface.
7. URL сопоставляется с правилами URL, зарегистрированными с помощью декоратора route() во время настройки приложения. Если соответствия нет, ошибка (обычно 404, 405 или перенаправление) сохраняется для обработки позже.
8. Отправляется сигнал request_started.
9. Вызываются любые функции, декорированные url_value_preprocessor().
10. Вызываются любые функции, декорированные before_request(). Если какая-либо из этих функций возвращает значение, оно сразу обрабатывается как ответ.
11. Если URL не сопоставился с маршрутом на предыдущих шагах, эта ошибка поднимается сейчас.
12. Вызывается функция-представление, декорированная route(), связанная с соответствующим URL, и возвращает значение, которое будет использоваться в качестве ответа.
13. Если на каком-либо шаге произошла ошибка, и есть функция, декорированная errorhandler(), которая соответствует классу исключения или коду HTTP-ошибки, она вызывается для обработки ошибки и возвращает ответ.
14. Любое значение, возвращающее ответ — функция перед запросом, представление или обработчик ошибок — преобразуется в объект Response.
15. Вызываются любые функции, декорированные after_this_request(), затем они очищаются.
16. Вызываются любые функции, декорированные after_request(), которые могут изменить объект ответа.
17. Сессия сохраняется, сохраняя любые измененные данные сессии с использованием интерфейса сессии приложения session_interface.
18. Отправляется сигнал request_finished.
19. Если на каком-либо шаге произошла ошибка, и она не была обработана функцией-обработчиком ошибок, она обрабатывается сейчас. HTTP-исключения обрабатываются как ответы с соответствующим кодом состояния, другие исключения преобразуются в универсальный ответ 500. Отправляется сигнал got_request_exception.
20. Статус, заголовки и тело объекта ответа возвращаются серверу WSGI.
21. Вызываются любые функции, декорированные teardown_request().
22. Отправляется сигнал request_tearing_down.
23. Контекст запроса удаляется, request и session больше недоступны.
24. Вызываются любые функции, декорированные teardown_appcontext().
25. Отправляется сигнал appcontext_tearing_down.
26. Контекст приложения удаляется, current_app и g больше недоступны.
27. Отправляется сигнал appcontext_popped.

Существует еще больше декораторов и точек настройки, которые не являются частью каждого жизненного цикла запроса. Они более специфичны для определенных вещей, которые вы можете использовать во время запроса, таких как шаблоны, создание URL-адресов или обработка данных JSON. Смотрите остальную часть этой документации, а также API для дальнейшего изучения.