FastStream - это относительно новая блестящая игрушка в руках Python'истов, которая создана специально для работы с брокерами сообщений.

В Python сложилось устойчивое убеждение, что если мы работаем с MQ - то нам нужен Celery, но он слегка устарел. Именно поэтому люди пытаются выкинуть "деда" и затащить вместо него любой новый многообещающий MQ-инструмент. Кроме того, культ Celery настолько силен в умах, что практически все новые библиотеки для работы с MQ пытаются стать его "убийцей" и заменой.

Однако, это не совсем верно. Существует огромный пласт проектов, которым нужен не фреймворк для менеджмента задач, а просто "голый" функционал Kafka/RabbitMQ/NATS/whatever для межсервисного взаимодействия. И все эти проекты вынуждены довольствоваться "сырыми" python-клиентами к своим брокерам, а всю обвязку вокруг этих клиентов писать самостоятельно. FastStream целится как раз в эту нишу.

В рамках статьи я хочу убедить вас, что не Celery мы едины, и для альтернативных инструментов найдется место под солнцем. А также рассмотрим фичи FastStream, которые он привносит в застоявшийся мир MQ-инструментов.

Привет, Habr! Возможно, кто-то меня даже помнит: совсем недавно я создал Python Framework для асинхронных приложений - Propan.

Два месяц назад я делился с вами прогрессом и говорил, что работа над PropanV2 активно ведется. И вот, она завершена. Вот только вместо PropanV2 свет увидел немного другой фреймворк - FastStream, разработкой которого занимался уже не только я, а целая команда AirtAI.

В рамках статьи я расскажу, чем проекты отличаются, как переехать с одного на другой, ну и конечно, как так вообще получилось. Если вам интересно, как я "продал" opensource проект, и как от этого все остались в выигрыше (особенно пользователи) - добро пожаловать под кат!

Пару месяцев назад я рассказал вам о своем фреймворке для работы с различными брокерами сообщений - Propan.

Тезисно повторю: это идейный наследник FastAPI, но для написания асинхронных микросервисов (привет, Kombu). Он настолько облегчает взаимодействие с брокерами сообщений, что данный архитектурный паттерн переходит из разряда

слишком сложно, это для хайлоад, некогда разбираться

в разряд

а давай отдадим нашему стажеру сервис, он по документации разберется

(Причем это реальный кейс)

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

Сейчас ваш фидбек очень важен, так как PropanV2 находится в активной работе и любое из ваших предложений сейчас может повлиять на него.

Декорирование функций - это, наверное, самая сложная среди базовых и самая простая среди продвинутых фич языка Python. С декораторами, наверное, знакомы все джуны (хотя бы в рамках подготовки к собеседованиям). Однако, крайне мало разработчиков пишут их правильно. Особенно принимая во внимания тенденции последних нескольких лет к аннотированию всего и вся. Даже популярные open-source проекты (если основная часть их кода была написана до 2018 года) вряд ли дадут вам примеры декораторов, отвечающих всем современным требованиям к коду.

Так давайте разбираться!

Материал полностью написан на основе моего опыта по работе над OSS проектами, поэтому в нем вы найдете примеры достаточно сложных кейсов, которые никогда не рассматриваются в других подобных гайдах. В то же время я постарался подвести к ним максимально "мягко", чтобы было понятно даже начинающим питонистам.

В рамках статьи мы разберемся с декорированием функций в Python от простого к самому сложному. Рассмотрим, как их правильно писать и аннотировать, чтобы другие потребители вашего кода не страдали от близкого знакомства с ним. Уверен, что даже если вы чрезвычайно опытный разработчик, вы найдете для себя полезные советы (хотя и можете пропустить солидную часть материала).

Я уверен, вы знаете, что такое FastAPI. По результатам опросов Stackoverflow этот фреймворк уверенно входит в топ любимых фреймворков не только питонистов, но и разработчиков в целом. И не зря: за счет свеого подхода к сериализации данных он предоставляет действительно потрясающий опыт разработки.

На Хабре уже была отличная статья о том, как устроен FastAPI изнутри. Там достаточно подробно рассмотрены все ключевые концепции этого фреймворка, а также разобраны детали его реализации на базе Starlette.

В этой же статье я хочу поделиться некоторым опытом создания своего инструмента для сериализации данных на основе pydantic. После прочтения этой статьи вы сможете превратить практически любой Python фреймворк в идейное подобие FastAPI. Причем речь идет не только об HTTP фреймворках. Никто не запрещает вам сделать, например, фреймворк для создания CLI, или telegram-ботов, или того, чего ваша душа пожелает.

Интересно? Тогда добро пожаловать!

Реализацией RPC запросов поверх брокеров сообщений никого не удивишь: очередь для запроса, очередь для ответа — ничего сложного.

Тот же RabbitMQ имеет пример в официальной документации. Других примеров там нет, поэтому создается впечатление, что отправка ответных сообщений в другую очередь — единственный возможный способ реализации RPC.

Этот сценарий отлично работает когда у нас есть непрерывный поток сообщений и непрерывный поток ответов на них. Однако, данный подход не применим в случаях, когда нам нужно отправить только одно сообщение и получить ответ именно на него. Мы сразу же попадаем в какой-то ад с фильтрацией ответов по correlation_id.

На самом деле, в RabbitMQ есть механизм и для такого сценария. Но он спрятан в недрах документации и о нем почти нет информации в интернете (особенно рабочих примеров кода).

Вот это недоразумение мы сейчас и исправим.

Всем привет! Так уж получилось, что совсем недавно, в процессе написания документации для проекта, мне пришлось перерыть всю официальную документацию RabbitMQ и тонну статей разного качества на тему разных видов маршрутизации в этом брокере.

Оказалось, что материала на эту тему много, но он либо объясняет совсем базовые случаи, либо уходит в такие дебри, которые крайне далеки и тяжелы для человека, который хочет "просто разобраться".

Простых и понятных примеров на Python тоже мало, так как они заставляют вас вникать не только в особенности различных вариантов маршрутизации RabbitMQ, но и в особенности используемых библиотек. Для человека, который видит что-то pika-подобное первый раз, это может быть испытанием.

Поэтому я и решил написать эту статью: она нацелена на "чайников" - вы легко можете показать ее вашим джунам, и этого уже должно быть достаточно для начала работы с RabbitMQ.

Примеры в статье будут приведены с использованием фреймворка Propan, чтобы не утруждать джуновский мозг лишними деталями установления соединения, канала и тд.

Так исторически сложилось, что последние 5 лет своей продуктовой разработки я работаю с микросервисами вокруг брокеров сообщений (преимущественно RabbitMQ и Kafka).

И все это время меня не покидало чувство некой неудовлетворенности и неполноценности инструментария, который был мне доступен.

Приходя из мира HTTP фреймворков ты чувствуешь себя как будто на костылях - ни тебе hotreload'а, который есть практически в любом wsgi-asgi сервере, хочешь тестировать - поднимай контейнеры окружения или мокай зависимости (особенно удобно в CI, ага), не забудь о реконнектах, логировании, трассировке и тд и тп.

И вот, таская от сервиса к сервису ворох всех этих проблем (и код который эти проблемы решает), до меня дошла гениальная идея: оформить весь однотипный код, общий для всех сервисов в единый пакет!

Так появился на свет фреймворк Propan.