Мелкая питонячая радость #2: Starlette
Тунельное зрение
Так уж сложилось, что на Python пишут много веб-приложений. Эту нишу Python разработки почти полностью поделили между собой два здоровых игрока — Django и Flask. Поэтому большой процент программистов, пишущих на Python, заточен на работу с этими двумя фреймворками.
По этой причине у многих Python-разрабов складывается некое подобие тунельного зрения — их инженерный подход заперт между этими двумя библиотеками.
Конечно, Django и Flask — отличные ребята, но довольно таки консервативные. Ведь за последние пару лет мир Python сильно уехал в сторону asyncio, а эти фреймворки так и остались в своей синхронной парадигме.
Часть программистов таки не заперлась между Djano и Flask и добавила в коллекцию своих боевых инструментов модный фреймворк Sanic и aiohttp (не совсем фреймворк, но штука популярная и веб-приложения на нем пилят успешно)
Тектонический сдвиг: от 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, но с корутинами и асихнронностью.
Разработчики Flask и Django оказались в заложниках своей аудитории — просто так взять и перевести свои фреймворки на асинхронный подход они не могут (это сломает код и уничтожит совместимость), поэтому вся разработка с применением ASGI оказалась сосредоточена в новых фреймворках, выпущенных в последние пару лет.
Вот и получается, что для всех желающих выжать из Python максимум производительности с помощью асинхронности и корутин, переход на новые фреймворки неизбежен.
Starlette — блистательный фреймворк
Starlette — новый, шустрый и классные фреймворк, реализующий подход ASGI. В нем все заточено на асинхронность и новые фишки 3-й ветки Python.
Кроме этого, в Starlette есть еще целая пачка серьезных плюшек.
- GraphQL из коробки. Да-да, этот новый подход к разработке клиент-серверных взаимодействий начинает выдавливать REST и занимает свое место в мире веб-фреймворков.
- Вебсокеты уже встроены и готовы к работе.
- Готовый набор миддлверов для работы с авторизацией/аутентификацией, CORS.
- Встроенные асинхронные таски (подобные Celery)
Солидная примочка — FastAPI
Некоторым программистам Starlette дико понравился и они создали расширение для этого фреймворка — FastAPI
FastAPI — это, по сути, нашлепка на родные классы Starlette, добавляющая пачку новых фич к уже и так неплохому фреймворку.
- Плюшки для создания RESP API сервисов + Swagger документация для методов. Starlette ориентируется на модный GraphQL, FastAPI заботится о тех, кто пилит REST.
- Удобные примочки, построенные на подсказках-типах переменных. Например, встроенные валидаторы данных.
- Приятные полезности для процессов авторизации и аутентификации — поддержка JWT, OAuth2.
И еще ряд мелких красивостей и удобностей.
В сухом остатке
Самое время погрузиться в мир ASGI и его фреймворков (если, конечно, вы еще этого не сделали). До доминирования на рынке асинхронным решениям пока далеко, но они активно наступают. И в первую очередь — из-за своей скорости.
