WSGI против ASGI
Вопрос
Сравните WSGI и ASGI. Когда вы выберете синхронный стек, а когда асинхронный?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
WSGI: синхронный вызов, запрос занимает воркер, просто и зрело
ASGI: корутины, события receive/send, WebSocket, стриминг, lifespan
Async выгоден при большом числе ожидающих I/O-запросов
Блокирующий код в async убивает выгоду
Django поддерживает оба, FastAPI только ASGI
Выбор зависит от библиотек и характера нагрузки
Что могут спросить следом
- Что будет с async-вьюхой Django под gunicorn sync?
- Как обслуживать WebSocket в Django?
Разбор
Образцовый ответ: «WSGI это синхронный интерфейс: сервер вызывает приложение функцией и ждёт ответ, запрос занимает процесс или поток целиком. Модель простая и зрелая, отлично подходит для классического CRUD с базой, где запросы короткие. ASGI асинхронный: приложение это корутина, которая общается с сервером событиями, поэтому один процесс держит тысячи одновременных соединений, а ещё поддерживаются WebSocket, стриминг и события запуска и остановки. Асинхронный стек выбираю, когда много ожидания I/O на запрос: вызовы внешних API, вебсокеты, чаты, прокси к другим сервисам. Важное условие: все библиотеки в горячем пути должны быть асинхронными, иначе один блокирующий вызов остановит процесс. Если команда пишет на Django с синхронным ORM и запросы короткие, WSGI под gunicorn проще и надёжнее. FastAPI работает только поверх ASGI, Django умеет оба режима, и для вебсокетов в Django берут ASGI с Channels».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.