Что такое WSGI и ASGI, в чем их разница и зачем они нужны

Что проверяют

Понимаете ли вы, что находится между вашим фреймворком и веб-сервером, и осознанно ли выбираете асинхронный стек. Вопрос быстро показывает, разворачивал ли человек приложение в прод или запускал только отладочный сервер.

Как отвечать

WSGI это стандартный интерфейс между сервером и Python-приложением: приложение это вызываемый объект, который принимает словарь environ и функцию start_response, а возвращает итерируемое тело ответа. Благодаря ему Flask и Django работают под gunicorn или uWSGI без привязки к конкретному серверу.

ASGI это его асинхронный преемник. Приложение это корутина с тремя аргументами: scope с типом и параметрами соединения, receive и send для обмена событиями. Событийная модель покрывает не только HTTP, но и WebSocket и жизненный цикл процесса, чего в WSGI нет в принципе.

def app(environ, start_response): ...     # WSGI: один синхронный вызов на запрос
async def app(scope, receive, send): ...  # ASGI: события, scope http или websocket

Про выбор: WSGI достаточен, когда приложение упирается в процессор и базу и живёт на синхронных драйверах. ASGI выигрывает там, где много одновременных соединений проводят время в ожидании: внешние API, стриминг, WebSocket, долгие вебхуки. Серверы для ASGI это uvicorn и hypercorn, фреймворки FastAPI, Starlette, современный Django; сшивает миры asgiref с sync_to_async и async_to_sync.

Где спотыкаются

Говорят, что WSGI обрабатывает запросы по очереди. Параллельность там есть, просто она снаружи: процессы и потоки воркеров, а при gevent и вовсе корутины. Ограничение не в последовательности, а в стоимости отдельного потока на каждое ждущее соединение.

Считают ASGI быстрее по определению. Синхронный код внутри асинхронного обработчика блокирует весь цикл событий, и одна долгая операция подвешивает все соединения воркера. Нужны асинхронные драйверы либо вынос блокирующего вызова в пул потоков.

Переводят проект на ASGI и оставляют синхронную ORM и библиотеки. Каждый вызов уезжает через sync_to_async в поток, выигрыша нет, а отладка усложняется. Переход имеет смысл под конкретную задачу, а не ради галочки в резюме.