Глава 22 · Веб-разработка с Python

WSGI и ASGI: связь веб-приложения с сервером

Фреймворк описывает, что делать с запросом. WSGI и ASGI — соглашение о том, как запрос до него доходит.

Раздел 22.18 упомянул WSGI и ASGI как техническую разницу между фреймворками. Разберём, что они означают на уровне идеи, без деталей реализации.

WSGI (Web Server Gateway Interface) и ASGI (Asynchronous Server Gateway Interface) — стандартные интерфейсы, описывающие, как сервер приложений передаёт HTTP-запрос Python-приложению и получает от него ответ. В обычном развёртывании сетевые соединения принимает сервер приложений или другая серверная инфраструктура, а не сам фреймворк (Flask, Django, FastAPI) напрямую — WSGI/ASGI и есть то общее соглашение между ними.

Flask и async — не то же самое, что ASGI-фреймворк

Flask умеет вызывать async def-обработчики, но само приложение при этом остаётся WSGI-приложением по архитектуре: для выполнения такого обработчика Flask запускает событийный цикл и выполняет в нём корутину, занимая при этом один обработчик запроса на всё время её работы. Это удобно, когда конкретному обработчику нужно ждать медленную операцию ввода-вывода, но не превращает Flask в полноценный ASGI-фреймворк вроде FastAPI — если приложению принципиально важна асинхронная модель на всех уровнях, ASGI-фреймворк подойдёт лучше.

Фреймворк и сервер приложений — разные вещи

Сам Flask или FastAPI описывает что делать с запросом. Отдельная программа — сервер приложений — отвечает за то, чтобы реально принять соединение по сети и передать запрос фреймворку по протоколу WSGI или ASGI:

К этому различию мы вернёмся в разделе 22.34 — сервер разработки, встроенный во Flask, и сервер приложений для рабочего окружения решают одну и ту же задачу по-разному.