Я сам столкнулся с тем, что какого-либо "продвинутого" материала по разработке почти нет. Если ты джун - вот тебе "hello world", но если решил сделать что-то дальше, то "ты уже большой мальчик, копай сам".
Поэтому и решил сделать что-то чуть более глубокое, чем обычные забивки в блогах. Тем более опыт и количество набитых шишек позволяет рассказать что-то интересное.
Если такой формат заходит, то скоро будет еще материал про оптимизацию Python кода на уровне синтаксиса (вангую, что сеньоры тоже удивятся некоторым выводам). Ну и разбор фишек 3.12 исходя из практики тоже на подходе.
Для этого у объекта, создаваемого с помощью build_model есть возможность дернуть непосредственно Pydantic модель, а от нее уже получить OpenAPI схему метода.
Я так и делаю для пвтоматческого составления AsyncAPI схемы приложения в Propan.
Появится немного свободного времени - постараюсь добавить публичный метод и документацию для этого юзкейса.
Возможно, вы пытались запустить этот скрипт напрямую через `python ...`, а не **PROPAN CLI**. Видимо, вы не открыли даже первую страницу документации или README того, что пытаетесь использовать. В любом случае, раз статья для начинающих, то я должен был и это предусмотреть... Так что добавил еще пару строчек с запуском в примеры.
Так, уже моя очередь извиняться, но это уже какая-то провокация и дезинформация с вашей стороны пошла. Все примеры полностью рабочие и делают именно то, что и описано. Я буквально только что пошел и прогнал их еще раз.
Спасибо за информацию. Я как-то и не задумывался даже, что кто-то захочет делать отправку через другой connection и channel. Насчет поднятия дополнительных channel не уверен насколько это оправдано для этого кейса. Если вы хотите прям бродкастить RPC, наверное, нам стоит все-таки создать для ответов полноценную очередь. Если вы хотите отправить 2-3 сообщения подряд, то лок не сыграет большой роли. Но я еще изучу этот вопрос и буду благодарен, если поможете с материалом на эту тему.
Забавно, что я аналогичным образом пришел к похожему решению где-то в апреле этого года. Правда, сейчас оно умеет немного больше, чем Mela: работает с RMQ, Nats, Kafka, SQS, Redis, помогает с тестированием, генерирует документацию для проекта и некоторые другие мелочи. Если вам интересно дальнейшее развитие этого направления, предлагаю объединить усилия. Вы можете ознакомиться с проектом на [GitHub](https://github.com/Lancetnik/Propan)
Возможно, вы правы: заголовок выбран не совсем удачно. Цель статьи - дать минимально необходимый набор информации, которой хватит для работы с RabbiMQ для людей, которые с ним вообще не знакомы. Как показывает практика, если грузить таких людей всей возможной информацией (либо даже упоминанием всего, что есть, но мы это не рассматриваем), то воспринимается это тяжело. Поэтому лучше сделать вид, что этой информации не существует (на данном этапе) а потом постепенно углублять полученные знания. В принципе, поэтому я и постарался оставить ссылками материалы, которые считаю полезными в качестве следующего шага для углубления знаний.
Если говорить о небольшом цикле статей, как вы считаете, какие механизмы стоит осветить следующими? Я думал об ack/nack/reject, туда же message ttl и dead letter exchanges/queues, либо написать о direct-reply, т.к. информации об этом механизме, как и примеров кода в интернете почти нет.
Это правда. Только это наименьшая проблема: нужно еще перелопатить эти json схемы в нормальный AsyncAPI документ с учетом специфики каждого брокера, потом сгенерировать из этого документа html файл (сейчас есть только консольная утилита для npm для этого), а потом захостить это документ на том же генераторе на ноде (либо в контейнере). Поэтому придется писать свой генератор html для питона + хостинг этой схемы самому писать, чтобы можно было оттуда запросы тестировать, т.к. такого функционала нигде нет. А это еще и фронт на реакте пилить... Ну и генерацию проекта из предоставленной схемы тоже пилить придется. В общем, процесс не быстрый.
Собственно, сейчас я и работаю над генерацией схем в соответствии с этой спецификацией. Правда, процесс очень не быстрый, так как нет никаких инструментов для python и придется лепить практически все с 0: от генерации схемы до ее html представления.
Хорошо, правда за вами: RFC 8259 утверждает, что просто значения тоже могут быть JSON, хотя и ссылается на то, что "в предыдущих стандартах JSON опеределялся только либо как object, либо как array" Видимо, я почему-то руководствовался всю жизнь однажды прочитанным старым стандартом 2013 года.
Ну, если речь о protobuf, то нет, не умеет. В перспективе - будет. Но вопрос был о json. Нет, можно посылать не только json. И нет, protobuf не умеем. Хотя, технически, вы можете легко его интегрировать в свой проект самостоятельно способом, который я описал выше.
Оно и не обязано быть json: можно послать все примитивные типы python, а сериализовать их при приеме с помощью pydantic. На крайний случай - можно принимать сырые bytes и сериализовать их самостотельно: например, в Depends, или прямо в теле функции.
Я сам столкнулся с тем, что какого-либо "продвинутого" материала по разработке почти нет. Если ты джун - вот тебе "hello world", но если решил сделать что-то дальше, то "ты уже большой мальчик, копай сам".
Поэтому и решил сделать что-то чуть более глубокое, чем обычные забивки в блогах. Тем более опыт и количество набитых шишек позволяет рассказать что-то интересное.
Если такой формат заходит, то скоро будет еще материал про оптимизацию Python кода на уровне синтаксиса (вангую, что сеньоры тоже удивятся некоторым выводам). Ну и разбор фишек 3.12 исходя из практики тоже на подходе.
Ну, скорее опечатка. Причем я ее с 5го раза только смог найти после того, как вы сказали. Спасибо, что заметили)
Именно, т.к. PydanticV2 написан на Rust, то либа получила существенный буст к производительности с его выходом.
Однако, она все еще совместима с PydanticV1, т.к. вторая версия сейчас, к сожалению, запускается не везде.
Для этого у объекта, создаваемого с помощью build_model есть возможность дернуть непосредственно Pydantic модель, а от нее уже получить OpenAPI схему метода.
Я так и делаю для пвтоматческого составления AsyncAPI схемы приложения в Propan.
Появится немного свободного времени - постараюсь добавить публичный метод и документацию для этого юзкейса.
Возможно, вы пытались запустить этот скрипт напрямую через `python ...`, а не **PROPAN CLI**. Видимо, вы не открыли даже первую страницу документации или README того, что пытаетесь использовать.
В любом случае, раз статья для начинающих, то я должен был и это предусмотреть...
Так что добавил еще пару строчек с запуском в примеры.
Так, уже моя очередь извиняться, но это уже какая-то провокация и дезинформация с вашей стороны пошла. Все примеры полностью рабочие и делают именно то, что и описано. Я буквально только что пошел и прогнал их еще раз.
Спасибо, действительно некоторое упущение. Немного подправил материал, чтобы этот момент стал яснее.
Спасибо за информацию. Я как-то и не задумывался даже, что кто-то захочет делать отправку через другой connection и channel. Насчет поднятия дополнительных channel не уверен насколько это оправдано для этого кейса. Если вы хотите прям бродкастить RPC, наверное, нам стоит все-таки создать для ответов полноценную очередь. Если вы хотите отправить 2-3 сообщения подряд, то лок не сыграет большой роли.
Но я еще изучу этот вопрос и буду благодарен, если поможете с материалом на эту тему.
Забавно, что я аналогичным образом пришел к похожему решению где-то в апреле этого года. Правда, сейчас оно умеет немного больше, чем Mela: работает с RMQ, Nats, Kafka, SQS, Redis, помогает с тестированием, генерирует документацию для проекта и некоторые другие мелочи. Если вам интересно дальнейшее развитие этого направления, предлагаю объединить усилия. Вы можете ознакомиться с проектом на [GitHub](https://github.com/Lancetnik/Propan)
Спасибо за замечание, поправил)
Возможно, вы правы: заголовок выбран не совсем удачно. Цель статьи - дать минимально необходимый набор информации, которой хватит для работы с RabbiMQ для людей, которые с ним вообще не знакомы. Как показывает практика, если грузить таких людей всей возможной информацией (либо даже упоминанием всего, что есть, но мы это не рассматриваем), то воспринимается это тяжело. Поэтому лучше сделать вид, что этой информации не существует (на данном этапе) а потом постепенно углублять полученные знания. В принципе, поэтому я и постарался оставить ссылками материалы, которые считаю полезными в качестве следующего шага для углубления знаний.
Если говорить о небольшом цикле статей, как вы считаете, какие механизмы стоит осветить следующими? Я думал об ack/nack/reject, туда же message ttl и dead letter exchanges/queues, либо написать о direct-reply, т.к. информации об этом механизме, как и примеров кода в интернете почти нет.
Ну, собственно, готово
https://lancetnik.github.io/Propan/ru/getting_started/9_documentation/
Это правда. Только это наименьшая проблема: нужно еще перелопатить эти json схемы в нормальный AsyncAPI документ с учетом специфики каждого брокера, потом сгенерировать из этого документа html файл (сейчас есть только консольная утилита для npm для этого), а потом захостить это документ на том же генераторе на ноде (либо в контейнере). Поэтому придется писать свой генератор html для питона + хостинг этой схемы самому писать, чтобы можно было оттуда запросы тестировать, т.к. такого функционала нигде нет. А это еще и фронт на реакте пилить...
Ну и генерацию проекта из предоставленной схемы тоже пилить придется. В общем, процесс не быстрый.
Собственно, сейчас я и работаю над генерацией схем в соответствии с этой спецификацией. Правда, процесс очень не быстрый, так как нет никаких инструментов для python и придется лепить практически все с 0: от генерации схемы до ее html представления.
Хорошо, правда за вами: RFC 8259 утверждает, что просто значения тоже могут быть JSON, хотя и ссылается на то, что "в предыдущих стандартах JSON опеределялся только либо как object, либо как array"
Видимо, я почему-то руководствовался всю жизнь однажды прочитанным старым стандартом 2013 года.
Тем, что это уже не является форматом JSON (согласно его спецификации)
Если честно, не вижу смысла развивать этот диалог в рамках статьи
Отправится как строка, на входе будет преобразовано в int в соответствии с аннотацией функции - потребителя
Из строки, например. Сообщение же может быть просто строкой/числом/bool, etc.
Ну, если речь о protobuf, то нет, не умеет. В перспективе - будет. Но вопрос был о json. Нет, можно посылать не только json. И нет, protobuf не умеем. Хотя, технически, вы можете легко его интегрировать в свой проект самостоятельно способом, который я описал выше.
Оно и не обязано быть json: можно послать все примитивные типы python, а сериализовать их при приеме с помощью pydantic. На крайний случай - можно принимать сырые
bytesи сериализовать их самостотельно: например, вDepends, или прямо в теле функции.