Мелкая питонячая радость #2: Starlette


    Туннельное зрение


    Так уж сложилось, что на 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 и его фреймворков (если, конечно, вы еще этого не сделали). До доминирования на рынке асинхронным решениям пока далеко, но они активно наступают. И в первую очередь — из-за своей скорости.

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 14

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

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

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

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

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

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

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

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

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

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

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

          Самое читаемое