Comments 11
Самый интересный вопрос - как обстоит дело с обработкой исключений?
Когда в Python 3.4 релизнули нативный asyncio, я надеялся, что вот-вот и весь этот кошмар с monkey.patch_all() уйдет в прошлое.
Но вот прошло 8 лет, а воз и ныне там. Большинство крупных проектов все еще либо на Django, либо Flask + SQLAlchemy и нормальной поддержкой асинхронности все еще не пахнет. Продакшн связка gevent + gunicorn все еще нестабильна, хотя все делают вид, что это работает.
Остается выбор, либо куча воркеров (дорого), либо нестандартные связки типа nginx + gevent.pywsgi + monkey.patch_all который "вроде как работает", но никто не знает и в какой момент выбранная вами библиотека перестанет работать с gevent и внезапно начнет вам блокировать основной поток.
Готов услышать альтернативные мнения, но сегодня я бы не стал использовать Python в качестве языка для серьезных проектов.
Ну, есть же fastapi, twisted и другие решения.
У нас на twisted + klein приложение обрабатывает миллионы запросов в сутки, не вижу особых мотиваторов на что-то переезжать.
Питон в продакшене у огромных контор и вполне себе работает. О серьезных проектах на flask или других threaded-wsgi в прочем сейчас уже речь не идет. Либо django для батерек из коробки, либо что-то асинхронное - fastapi, starlite и тд.
Все асинхронные либы используем сразу, синхронные пихаем в тредпул.
Что вы используете/советуете для ORM? Последний раз когда я смотрел (пару лет назад), адекватных замен SQLAlchemy или Django ORM, да что бы еще и с полноценной поддержкой asyncio просто не было.
Например, у нас в проекте 120+ таблиц/моделей SQLAlchemy, огромное количество связей между ними, кэширования, joinedload/noload, lazy, итд. Создавать и поддерживать такой функционал без полноценной ORM это ад.
Можно поподробнее про тредпул? Каким образом вы это делаете и как это решает концептуальную проблему с GIL?
GIL является же проблемой для CPU-bound потоков, но для IO-bound оно никогда проблемой не было, ни концептуальной, ни какой-то ещё
Алхимия асинхронная с 1.4 работает хорошо.
Есть ещё Tortoise ORM асинхронный клон Django ORM. Ormar - интересная надстройка над алхимией.
Рекомендаций по ORM не дам - у нас просто асинхронный коннектор к БД и круды. Необходимости делать множественные джойны отсутствует, так как основной объект имеет часть инфы как binary-json (postgres). Часть реляционной схемы съедена, что имеет свои минусы и плюсы.
Год назад проверял по алхимии и она было только частично async, сейчас вроде они полностью мигрировали. Есть асинхронные ORM вроде tortoise, не пользовался по серьезному.
Тредпул это просто имитация асинхронности для блокирующего кода. Условно у нас есть эндпоинт который читает с базы и допустим делает запрос куда-нибудь, функция которая делает запрос уже написана и использует requests - блокирующую либу. Мы делаем threads.deferToThread (это в twisted, в асинкио есть аналоги) и задачка помещается в очередь на выполнение тредпулом. Запрос это IO задача, то есть поток сразу уходит спать пока не получит ответ. Проблема с GIL может быть только для CPU-bound задач. Возможно потому что ORM у нас нет - проблем с загрузкой процессора тоже нет
библиотеки более верхнего уровня, вроде django-rest-framework и других, тоже работают без всяких модификаций
Разве можно асинхронный queryset обернуть в Response из DRF? Или я что-то не так понял?)
Новый взгляд на асинхронность в Python: в лучших традициях gevent, но ещё лучше