Туннельное зрение
Так уж сложилось, что на Python пишут много веб-приложений. Эту нишу Python разработки почти полностью поделили между собой два здоровых игрока — Django и Flask. Поэтому большой процент программистов, пишущих на Python, заточен на работу с этими двумя фреймворками.
По этой причине у многих Python-разрабов складывается некое подобие туннельного зрения — их инженерный подход заперт между этими двумя библиотеками.
Часть программистов не ограничивается Djano и Flask и добавляет в своих боевые инструменты всякие новые штуки. Например, модный фреймворк Sanic.
Тектонический сдвиг: от WSGI к ASGI
В период бурной адаптании Python к нуждам веб-разработки сообщество придумало стандарт WSGI — Web Server Gateway Interface. Этот протокол описывал то, как веб-сервер мог передавать HTTP запросы на обработку в Python приложения и получать оттуда ответы.
WSGI открыл путь для разработки множества фреймворков и библиотек для веб-разработки. Все они были разные по своей архитектуре, но одинаковые по своему способу общения с внешним веб-сервером. WSGI был представлен сообществом аж в 2003-м году и все популярные классические питонячие веб-фреймворки (включая Django и Flask) поддерживают его до сих пор.
Проблемы с WSGI начались после того, как в ядре Python появились мощные средства для асинхронного выполнения кода и корутины. WSGI стар и никак не заточен на работу с новыми фишками языка. Поэтому появилась потребность в новом, асинхронном протоколе общения веб-сервера с Python программами. Так и появился ASGI (Asynchronous Server Gateway Interface) — идеологический потомок WSGI, но с корутинами и асихнронностью.
Разработчики старых фреймворков оказались в заложниках своей аудитории — просто так взять и перевести свои фреймворки на асинхронный подход они не могут (это сломает код и уничтожит совместимость), поэтому вся разработка с применением ASGI оказалась сосредоточена в новых фреймворках, выпущенных в последние пару лет, и Django.
Starlette — блистательный фреймворк
Starlette — новый, шустрый и классные фреймворк, реализующий подход ASGI. В нем все заточено на асинхронность и новые фишки 3-й ветки Python.
Кроме этого, в Starlette есть еще целая пачка серьезных плюшек.
- GraphQL из коробки. Да-да, этот новый подход к разработке клиент-серверных взаимодействий начинает выдавливать REST и занимает свое место в мире веб-фреймворков.
- Вебсокеты уже встроены и готовы к работе.
- Готовый набор миддлверов для работы с авторизацией/аутентификацией, CORS.
- Встроенные асинхронные таски.
Солидная примочка – FastAPI
Некоторым программистам Starlette дико понравился и они создали расширение для этого фреймворка — FastAPI
FastAPI — это, по сути, нашлепка на родные классы Starlette, добавляющая пачку новых фич к уже и так неплохому фреймворку.
- Плюшки для создания REST API сервисов + Swagger документация для методов. Starlette ориентируется на модный GraphQL, FastAPI заботится о тех, кто пилит REST.
- Удобные примочки, построенные на подсказках-типах переменных. Например, встроенные валидаторы данных.
- Приятные полезности для процессов авторизации и аутентификации — поддержка JWT, OAuth2.
И еще ряд мелких красивостей и удобностей.
В сухом остатке
Самое время погрузиться в мир ASGI и его фреймворков (если, конечно, вы еще этого не сделали). До доминирования на рынке асинхронным решениям пока далеко, но они активно наступают. И в первую очередь — из-за своей скорости.
Комментарии (14)
robert_ayrapetyan
06.06.2019 16:15Не стоит вводить людей в заблуждение ложными утверждениями. Все современные (и даже откровенно старые, типа Pyramid) фреймворки «легким, непринужденным движением» превращаются в асинхронные. Почти каждый имеет для этого готовый модуль (flask-aiohttp, aiopyramid и др.), который в связке с тем же asyncio, асинхронным воркером gunicorn или uwsgi позволяет реализовывать асинхронные интерфейсы, не меняя код самого фреймворка.
57uff3r Автор
06.06.2019 16:24Здесь речь о решениях, изначально спроектированных под асинхронщину и поддерживающих ее с самого начало своей жизни. Конечно, если покопаться, то можно найти много библиотек, чьи названия начинаются с префикса aio и они как-то добавляют какой-то асинхронности в код. И делают они это далеко не всегда самым чистым, понятным и быстрым способом.
Это некие попытки сохранить статус кво и пилить асинхронный код на старых либах. Такое может понадобиться, например, тем, у кого большие обьемы легаси, которые никак не перписать, но асинхронность из старого кода нужно как-то выжать.
Однако вся движуха идет вокруг новых либ, там собирается сообщество и идут коммиты и активная разработка.
flask-aiohttp, aiopyramid и прочие штуки, конечно, номинально существуют, но они еле-еле набирают 100 звезд на гитхабе и последние коммиты были в них несколько лет назад.robert_ayrapetyan
06.06.2019 16:44Сравнение «новых» и «старых» асинхронных подходов было бы куда полезнее. Как по мне, имея сверху питоновский await, снизу OS-specific event loop, абсолютно пофиг, что находится между ними — плагин к синхронному фреймворку, или «фреймворк, поддерживающий асинхронщину с самого начала его жизни». Вместо этого статья, как мне кажется, выстроена на ложном утверждении.
57uff3r Автор
06.06.2019 16:54И что же это за утверждение?
robert_ayrapetyan
06.06.2019 17:11+1>Ведь за последние пару лет мир Python сильно уехал в сторону asyncio, а эти фреймворки так и остались в своей синхронной парадигме.
При этом вас не смущает, что тот же ASGI зародился в экосистеме django и написан, в первую очередь, под него, и прекрасно с ним работает.
По поводу гитхаба и звезд — базовые вещи (а именно простые оббертки над чем-то более сложным) редко получают апдейты. Хотя aiopyramid не мешало бы обновить.
А у Starlette нет и сотой части модулей и плагинов из мира flask\django.
NerVik
06.06.2019 20:33Я только хотел попробовать этот старлетт, как вышла новость, что джанга со следующей версии 3.0 начинает становиться асинхронной, и после этого как-то непонятно стало зачем мне нужно что-то другое..
kalbas
В доке написано, что production-ready. Интересно, кто уже использует?
57uff3r Автор
Авторы фреймворка юз-кейсы не публикуют, к сожалению.
Субъективно могу сказать, что у себя мы собрали 2 приложения, они стабильно работают под нагрузкой порядка 10-20 запросов/секунду и пока не падали. Из неприятного нашлась мелкая бага с CORS, авторы ее успешно вылечили в версии 0.12
em92
Использую портированную под Python 3.5 в связке с uvicorn в этом проекте. Сам проект в техническом плане — простой (запрос-ответ. Без вебсокетов, GraphQL, асинхронных заданий и прочего).
Единственная багу, которую заметил — это не могу преврать выполнение события startup с помощью Ctrl+C. Приходится уничтожать процесс с помощью «kill -9 $pid». Предполагаю, что этот пачт решит проблему, но на практике не пробовал.