Знакомство с FastAPI
В нашей команде бытует хорошая практика фиксировать всё изменения, которые отправляются в продакшен в гитхабовских релизах. Однако, не вся наша команда имеет доступ в гитхаб, а о релизах хочется знать всем. Так сложилась традиция релиз из гитхаба дублировать в рабочем чате команды в телеграме. Что хорошо, гитхаб позволяет с помощь маркдауна красиво оформить релиз с разделением на секции и ссылками на задачи, которые отправляются на выкатку. Что плохо, простым copy/paste всю эту красоту в телеграм не перенесёшь и приходится тратить время на довольно нудную работу по повторному оформлению релиза, но уже в телеграме. Ну а посколько программисты народ ленивый, я решил этот процесс автоматизировать.
Исходные данные:
Соответственно, задача заключается в том, чтобы поднять HTTP API, который сможет принять POST запрос, проверить подпись, извлечь нужную информацию из тела запроса и передать её дальше по инстанции. Как тут не попробовать FastAPI, на который я давно глаз положил?
Кто такой FastAPI?
FastAPI — это фреймворк для создания лаконичных и довольно быстрых HTTP API-серверов со встроенными валидацией, сериализацией и асинхронностью,
что называется, из коробки. Стоит он на плечах двух других фреймворков: работой с web в FastAPI занимается Starlette, а за валидацию отвечает Pydantic.
Комбайн получился легким, неперегруженным и более, чем достаточным по функционалу.
Необходимый минимум
Для работы FastAPI необходим ASGI-сервер, по дефолту документация предлагает uvcorn, базирующийся на uvloop, однако FastAPI также может работать и с другими серверами, например, c hypercorn
Вот мои зависимости:
И этого более чем достаточно.
Для более тщательных читателей в конце статьи есть ссылка на репозиторий с ботом, там можно посмотреть на зависимости для разработки и тестирования.
Собираем API
Надо заметить, что подход к оформлению хэндлеров в FastAPI чрезвычайно напоминает такой же в Flask, Bottle, да тысячи их. Видимо, миллионы мух не могут-таки ошибаться.
В самом первом приближении мой роут для обработки релиза выглядел так:
Здесь прекрасно видно, как выглядят модели Pydantic. Их можно вкладывать, причем как сущностями, так и списками, к примеру так:
Ещё мы обязаны задать типы полям моделей и FastAPI будет мапить входящий запрос на переданную ему модель с учётом типов. В случае несовпадения он отдаст ошибку валидации. В случае, если поля во входящих данных нет и в модели не проставлено значение по-умолчанию — тоже.
Кроме базовых питоньих типов Pydantic предлагает ещё достаточно много своих собственных типов данных, в моём примере это тип HttpUrl, то есть входящая строка должна быть валидным URL со схемой и доменом первого уровня, в противном случае FastAPI отдаст ошибку валидации. Остальные типы Pydantic можно посмотреть здесь
Таким образом валидация и сериализация данных настраивается уже при задании модели данных.
Аутентификация
FastAPI поддерживает достаточно методов аутентификации по умолчанию, но, поскольку здесь используется гитхабовская подпись запроса, авторизацию пришлось колхозить самостоятельно,
ну да оно и к лучшему — больше интересного!
Я вынес роуты FastAPI в отдельный роутер, а в основном файле оставил авторизацию и управление документацией:
Обратите внимание, что request.body — это функция, причем асинхронная. В FastAPI(а на деле в Starlette) асинхронность везде, это надо обязательно помнить.
Что касается документации, то это ещё один большой плюс FastAPI — он автоматически генерит документацию в формате OpenAPI и отдаёт её в формате Swagger/ReDoc в зависимости от где вы смотрите, ваш_сайт/docs или ваш_сайт/redoc соответственно.
В моем случае я решил документацию в проде вообще убрать. Ну его.
Соответственно, файл с роутами превратился в это:
А всё
Это действительно весь код, который запускает быстрый HTTP API-сервер с аутентификацией, валидацией и документацией.
Итого
FastAPI — действительно отличный инструмент, если вам по душе лаконичность и, вместе с тем, понятность кода. Кроме того, он асинхронен(фу, вы что, в 2020-ом году пишете синхронный код?
я тоже), быстр и это не идёт в ущерб функциональности.
Так что если на горизонте маячит новый проект, для которого важны производительность, документация и валидация, то, вероятно, имеет смысл посмотреть в сторону FastAPI.
Вместо послесловия
Конечно, проект получился несколько больше, чем описанные мной три файла. Там их на самом деле шесть — собственно бот, описывать которого я не стал, ибо нерелевантно, а также утилиты и настройки, вынесенные в отдельные файлы для большего порядку.
Всё это, а также тесты, докерфайл и настройку github actions вы можете посмотреть в исходном коде проекта
Введение в ASGI: становление асинхронной веб-экосистемы Python
Привет, Хабр! Представляю вашему вниманию перевод статьи «Introduction to ASGI: Emergence of an Async Python Web Ecosystem» автора Florimond Manca.
«Черепахи рядом с водоемом», Ricard Baraham на unsplash.com
Python не замыкается только на Data Science, веб-разработка на Python вернулась с новым асинхронным витком в развитии языка!
Сейчас происходит много важных событий в экосистеме веб-разработки на Python. Одним из основных драйверов этих изменений является ASGI — Asynchronous Standard Gateway Interface.
Я уже несколько раз упоминал ASGI в моем блоге, в частности, когда анонсировал Bocadillo (асинхронный open-source веб-фреймворк на Python — прим.пер.) и tartiflette-starlette (библиотека для построения GraphQL API поверх HTTP через ASGI — прим.пер.), но я никогда не писал подробное введение о нем. Теперь я это сделаю.
Эта статья нацелена на людей, интересующихся последними трендами в веб-разработке на Python. Я хочу пригласить вас на экскурсию, из которой вы узнаете, что такое ASGI, и что он означает для современной веб-разработки в мире Python.
Прежде чем мы начнем, я хотел бы рассказать, что недавно создал awesome-asgi — отличный список для отслеживания постоянно расширяющейся экосистемы ASGI.
Все началось с async/await
В отличие от JavaScript или Go, в момент появления Python не предоставлял возможность асинхронного исполнения кода. Долгое время параллельное выполнение кода в Python могло быть реализовано только с помощью многопоточной или многопроцессорной обработки, либо с использованием специализированных сетевых библиотек, таких как eventlet, gevent или Twisted. (Еще в 2008 году у Twisted был API для асинхронных корутин, например, в виде inlineCallbacks и deferredGenerator )
Началась сумасшедшая гонка! С момента выпуска версии 3.5 сообщество буквально асинхронизовывает все вокруг. Если вам интересно, многие из получившихся проектов перечислены в aio-libs и awesome-asyncio.
Как вы догадались, это также означает, что веб-серверы и приложения на Python движутся в сторону асинхронности. На самом деле, все крутые ребята делают это! (Даже Django) (Habr: Django 3.0 будет асинхронным, уже вышла 02.12.2019 — прим.пер.)
Обзор ASGI
Итак, как же ASGI вписывается во все это?
Верхнеуровнево ASGI можно рассматривать как связующее звено, которое позволяет асинхронным Python серверам и приложениям взаимодействовать друг с другом. Он повторяет множество архитектурных идей из WSGI, и зачастую представляется как его преемник со встроенной асинхронностью.
Вот так его можно изобразить на диаграмме:
На очень высоком уровне ASGI — это интерфейс для коммуникации между приложениями и серверами. Но на самом деле, все немного сложнее.
Чтобы разобраться, как ASGI действительно работает, давайте взглянем на спецификацию ASGI.
ASGI состоит из двух различных компонентов:
Таким образом, согласно спецификации, то, что действительно указывает ASGI — это формат сообщения и то, как эти сообщения должны передаваться между приложением и сервером протокола, который его запускает.
Теперь мы можем составить более детальную версию диаграммы:
В протоколе есть еще много более интересных деталей. Например, вы можете взглянуть на спецификацию HTTP и WebSocket.
Кроме того, хотя спецификация сильно фокусируется на взаимодействии между сервером и приложением, ASGI удается охватить гораздо больше аспектов.
Мы доберемся до этого через минуту, но сначала…
Основы ASGI
Теперь, когда мы увидели, как ASGI вписывается в веб-экосистему Python, давайте более подробно рассмотрим, как это воплощается в коде.
ASGI опирается на простую модель: когда клиент подключается к серверу, создается экземпляр приложения. Затем входящие данные передаются в приложение и отправляются обратно все данные, которые оно возвращает.
Передача данных в приложение здесь в действительности означает вызов приложения, как если бы оно было функцией, т.е. чем-то, что принимает некоторые входные данные и возвращает выходные.
На самом деле, все, что представляет собой ASGI-приложение — это callable (вызываемый объект). Параметры этого вызываемого объекта, опять же, определяются спецификацией ASGI:
Сигнатура этой функции — это как раз то, что означает «I» в «ASGI»: интерфейс, который должно реализовать приложение, чтобы сервер смог его вызвать.
Давайте рассмотрим параметры функции:
По сути, эти параметры позволяют получать ( receive() ) и передавать ( send() ) данные по каналу связи, который поддерживает сервер протокола, а также понимать, в каком контексте (или scope ) этот канал был создан.
Не знаю как вам, но мне очень нравятся общий вид и структура этого интерфейса. В любом случае, сейчас посмотрим на пример кода.
Покажите код!
Чтобы получить практическое представление о том, как выглядит ASGI, я создал минимальный проект на голом ASGI, который демонстрирует HTTP-приложение, обслуживаемое uvicorn (популярный ASGI-сервер):
Здесь мы используем send() для отправки HTTP-ответа клиенту: сначала отправляем заголовки, а затем тело ответа.
К счастью, есть варианты более высокого уровня — и именно тогда я начинаю говорить о Starlette.
Starlette — поистине фантастический проект, и, по-моему, фундаментальная часть экосистемы ASGI.
Кратко, он предоставляет набор высокоуровневых компонентов, таких как запросы и ответы, которые можно использовать, чтобы абстрагироваться от некоторых деталей ASGI. Вот, взгляните на «hello world» в Starlette:
В Starlette есть все, что вы ожидаете от настоящего веб-фреймворка — routing, middleware и т.д. Но я решил показать эту урезанную версию, чтобы намекнуть на реальную силу ASGI, которая является…
Черепахи на всем пути
Интересная и меняющая правила игры концепция ASGI — это «Черепахи на всем пути», выражение, которое первоначально придумал (я думаю?) Andrew Godwin, создавший Django Migrations и сейчас занимающийся переработкой Django для поддержки асинхронности.
Но что именно это означает?
Поскольку ASGI это абстракция, которая позволяет сказать, в каком контексте мы находимся, и получать и отправлять данные в любое время, то есть идея, что ASGI можно использовать не только между серверами и приложениями, но и действительно в любой точке стека.
Например, объект Starlette Response это само приложение ASGI. На самом деле, мы можем сократить код в примере приложения выше до такого:
Насколько нелепо это выглядит?!
Но подождите, это еще не все.
Более глубокое следствие «черепах на всем пути» заключается в том, что мы можем создавать всевозможные приложения, middleware, библиотеки и другие проекты и гарантировать, что они будут совместимыми до тех пор пока они все реализуют интерфейс приложения ASGI.
(К тому же, из моего личного опыта построения Bocadillo, прием интерфейса ASGI очень часто (если не всегда) приводит к гораздо более чистому коду)
Например, мы можем создать ASGI middleware (т.е. приложение, которое обертывает другое приложение), чтобы отобразить время, за которое был выполнен запрос:
Чтобы использовать его, мы просто оборачиваем им приложение…
… и это будет волшебным образом просто работать.
Восхитительно, что в TimingMiddleware можно обернуть любое ASGI-приложение. Внутреннее приложение в этом примере супер-простое, но это может быть полноценный, реальный проект (представьте сотни API и WebSocket endpoint-ов) — это не имеет значения, пока интерфейс совместим с ASGI.
(Есть версия этого middleware более подготовленная к промышленному использованию: timing-asgi.)
Почему это должно волновать?
Хотя я думаю, что совместимость является очень сильным аргументом, есть еще много преимуществ в использовании компонентов на основе ASGI для построения веб-приложений Python.
С точки зрения библиотек и инструментов, не думаю, что мы можем сказать, что добрались до необходимого уровня. Но благодаря очень активному сообществу, у меня есть большие надежды, что экосистема ASGI очень скоро достигнет паритета функций с традиционной синхронной/WSGI экосистемой.
Где можно найти компоненты, совместимые с ASGI?
На самом деле, все больше и больше людей строят и улучшают проекты на основе ASGI. Очевидно, это серверы и веб-фреймворки, но также есть middleware и ориентированные на продукт приложения, такие как Datasette.
Ниже несколько примеров компонентов, не являющихся веб-феймворками, которые меня интересуют:
Восхитительно наблюдать, что экосистема успешно развивается, однако, мне лично было трудно не отставать от изменений.
Именно поэтому я создал awesome-asgi. Я надеюсь, что это поможет всем идти в ногу со всеми удивительными вещами, которые происходят в мире ASGI. (И видя, что он почти достиг 100 звезд за несколько дней, у меня есть ощущение, что действительно была необходимость собрать в одном месте информацию о ресурсах про ASGI.)
Выводы
Хотя это может выглядеть как подробности реализации, я уверен, что ASGI заложил основы для новой эры в веб-разработке на Python.
Эти проекты были созданы и поддерживаются компанией Encode, в основном Томом Кристи (Tom Christie). Есть открытые обсуждения по созданию команды поддержки Encode, так что если вы искали возможность поучаствовать в разработке open-source, то у вас есть такая возможность!
Получайте удовольствие от путешествия в мир ASGI!
Introduction
Starlette is a lightweight ASGI framework/toolkit, which is ideal for building high performance asyncio services.
It is production-ready, and gives you the following:
Requirements
Installation
You’ll also want to install an ASGI server, such as uvicorn, daphne, or hypercorn.
Example
example.py:
Then run the application.
For a more complete example, see here.
Dependencies
Framework or Toolkit
Starlette is designed to be used either as a complete framework, or as an ASGI toolkit. You can use any of its components independently.
Run the app application in example.py :
Modularity
The modularity that Starlette is designed on promotes building re-usable components that can be shared between any ASGI framework. This should enable an ecosystem of shared middleware and mountable applications.
The clean API separation also means it’s easier to understand each component in isolation.
Performance
Independent TechEmpower benchmarks show Starlette applications running under Uvicorn as one of the fastest Python frameworks available. (*)
For high throughput loads you should:
Several of the ASGI servers also have pure Python implementations available, so you can also run under PyPy if your application code has parts that are CPU constrained.
Starlette is BSD licensed code. Designed & built in Brighton, England.
Мелкая питонячая радость #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 есть еще целая пачка серьезных плюшек.
Солидная примочка – FastAPI
Некоторым программистам Starlette дико понравился и они создали расширение для этого фреймворка — FastAPI
FastAPI — это, по сути, нашлепка на родные классы Starlette, добавляющая пачку новых фич к уже и так неплохому фреймворку.
И еще ряд мелких красивостей и удобностей.
В сухом остатке
Самое время погрузиться в мир ASGI и его фреймворков (если, конечно, вы еще этого не сделали). До доминирования на рынке асинхронным решениям пока далеко, но они активно наступают. И в первую очередь — из-за своей скорости.
starlette 0.17.1
pip install starlette Copy PIP instructions
Released: Nov 17, 2021
The little ASGI library that shines.
Navigation
Project links
Statistics
View statistics for this project via Libraries.io, or by using our public dataset on Google BigQuery
License: BSD License (BSD)
Requires: Python >=3.6
Maintainers
Classifiers
Project description
✨ The little ASGI framework that shines. ✨
Starlette
Starlette is a lightweight ASGI framework/toolkit, which is ideal for building high performance async services.
It is production-ready, and gives you the following:
Requirements
Installation
You’ll also want to install an ASGI server, such as uvicorn, daphne, or hypercorn.
Example
example.py:
Then run the application using Uvicorn:
For a more complete example, see encode/starlette-example.
Dependencies
Framework or Toolkit
Starlette is designed to be used either as a complete framework, or as an ASGI toolkit. You can use any of its components independently.
Run the app application in example.py :
Modularity
The modularity that Starlette is designed on promotes building re-usable components that can be shared between any ASGI framework. This should enable an ecosystem of shared middleware and mountable applications.
The clean API separation also means it’s easier to understand each component in isolation.
Performance
Independent TechEmpower benchmarks show Starlette applications running under Uvicorn as one of the fastest Python frameworks available. (*)
For high throughput loads you should:
Several of the ASGI servers also have pure Python implementations available, so you can also run under PyPy if your application code has parts that are CPU constrained.
Starlette is BSD licensed code. Designed & built in Brighton, England.