Pull to refresh

Comments 14

В доке написано, что production-ready. Интересно, кто уже использует?
Авторы фреймворка юз-кейсы не публикуют, к сожалению.

Субъективно могу сказать, что у себя мы собрали 2 приложения, они стабильно работают под нагрузкой порядка 10-20 запросов/секунду и пока не падали. Из неприятного нашлась мелкая бага с CORS, авторы ее успешно вылечили в версии 0.12
Интересно, кто уже использует?

Использую портированную под Python 3.5 в связке с uvicorn в этом проекте. Сам проект в техническом плане — простой (запрос-ответ. Без вебсокетов, GraphQL, асинхронных заданий и прочего).

Единственная багу, которую заметил — это не могу преврать выполнение события startup с помощью Ctrl+C. Приходится уничтожать процесс с помощью «kill -9 $pid». Предполагаю, что этот пачт решит проблему, но на практике не пробовал.
Не стоит вводить людей в заблуждение ложными утверждениями. Все современные (и даже откровенно старые, типа Pyramid) фреймворки «легким, непринужденным движением» превращаются в асинхронные. Почти каждый имеет для этого готовый модуль (flask-aiohttp, aiopyramid и др.), который в связке с тем же asyncio, асинхронным воркером gunicorn или uwsgi позволяет реализовывать асинхронные интерфейсы, не меняя код самого фреймворка.
Здесь речь о решениях, изначально спроектированных под асинхронщину и поддерживающих ее с самого начало своей жизни. Конечно, если покопаться, то можно найти много библиотек, чьи названия начинаются с префикса aio и они как-то добавляют какой-то асинхронности в код. И делают они это далеко не всегда самым чистым, понятным и быстрым способом.

Это некие попытки сохранить статус кво и пилить асинхронный код на старых либах. Такое может понадобиться, например, тем, у кого большие обьемы легаси, которые никак не перписать, но асинхронность из старого кода нужно как-то выжать.

Однако вся движуха идет вокруг новых либ, там собирается сообщество и идут коммиты и активная разработка.
flask-aiohttp, aiopyramid и прочие штуки, конечно, номинально существуют, но они еле-еле набирают 100 звезд на гитхабе и последние коммиты были в них несколько лет назад.
Сравнение «новых» и «старых» асинхронных подходов было бы куда полезнее. Как по мне, имея сверху питоновский await, снизу OS-specific event loop, абсолютно пофиг, что находится между ними — плагин к синхронному фреймворку, или «фреймворк, поддерживающий асинхронщину с самого начала его жизни». Вместо этого статья, как мне кажется, выстроена на ложном утверждении.
И что же это за утверждение?
>Ведь за последние пару лет мир Python сильно уехал в сторону asyncio, а эти фреймворки так и остались в своей синхронной парадигме.

При этом вас не смущает, что тот же ASGI зародился в экосистеме django и написан, в первую очередь, под него, и прекрасно с ним работает.

По поводу гитхаба и звезд — базовые вещи (а именно простые оббертки над чем-то более сложным) редко получают апдейты. Хотя aiopyramid не мешало бы обновить.

А у Starlette нет и сотой части модулей и плагинов из мира flask\django.
С Django явный косяк, сейчас исправлю эту часть, спасибо.

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

Вот только выйдет она не известно когда…

по родмапу в декабре обещают

А не могли бы Вы, пожалуйста, дать ссылку на эту новость?
Sign up to leave a comment.

Articles