Мне очень нравятся буллетпоинты, где одно и то же переформулировано несколько раз и выдается под видами "вот вам 5 преимуществ Next JS" + возвращаемся к SEO через каждые 3 слова. Можно, пожалуйста, меньше использовать GPT для генерации материала для блога? Это как минимум неуважительно - люди должны тратить время на прочтение, а вы даже не потратили его на написание/редактуру.
В статье заявлен разбор "всех преимуществ Next", но поговорили только о SSR и SSG (хотя и неплохо для джунов). В общем, пожалуйста, работайте над материалом перед его выкладыванием.
абстракция в лучшем случае сохранит эти возможности, а в худшем сузит предоставляемый API
Абстракция может не только "сохранить в лучшем случае", но и приумножить. Например, тот же Celery расширяет функциональные возможности голых брокеров (пряча оригинальные, но мог бы и не делать этого)
Предположим, что наш разработчик пишет сложный в тестировании код, тяжелый в развертывании и сопровождении.
Вот вы набрасываете, но не аргументируете. Я спрашиваю - "как вы будете тестировать контракты в асинхронном взаимодействии?". Это не вина разработчика, что он не смог. У него просто нет для этого инструментов
А тут уже откровенно начинаем говорить о околонулевом опыте "вайтишника"
В написанном коде всегда будут ошибки. Не важно, пишете его вы, я или "вайтишник". Если этот код написал разработчик библиотеки, а протестировали его тысячи других пользователей - шанс на ошибку в разы меньше
А вы уверены, что с ними так все хорошо? Давайте пройдемся по ним, чтоли
1) RabbitMQ - тут, слава богу, все хорошо. Есть официальная pika, вот только она синхронная, не везде подойдет. Есть Дмитрий Орлов и его aio-pika - клиент феноменального качества, вот только это обертка над aiormq, который обертка над pamqp.
Какой уровень абстракций вы считаете приемлимым? - Мне не очень понятно
2) Kafka. Ну, тут у нас весело - есть confluent-kafka, которая просто python-биндинги поверх C библиотеки. И падает оно с segfault на каждый чих. Отличная "библиотека от вендора". Есть еще aiokafka - но она же не от вендора, да и не все фичи самой Kafka поддерживает
3) NATS. Еще веселее. nats-py клиент пишет человек из core-команды NATS. Вот только он же пишет и ruby клиент. И язык Python для него не основной. Я нашел МНОГО багов, пока реализовывал поддержку NATS в FastStream поверх этой библиотеки. Часть пофиксили через PR в nats-py, часть получилось обойти на уровне кода. Еще одна прекрасная библиотека от вендора
4) SQS. Тут у нас botocore (синхронный) и aiobotocore (асинхронный) ну и прочие boto3. Это абсолютно непригодные для разработки инструменты, тк банально не имеют ни автокомплитов в IDE, ни проверки типов - это просто классы, которые конструируются в рантайме, поэтому ваш код на момент написания ничего не знает об их поведении
Я не буду продолжать по всем брокерам, просто хочу сказать, что "нативные библиотеки" - это не всегда лучшее решение. В большинстве случаев потом что сам инструмент разрабатывался на одном языке, а клиенты нужны - под все. И у разработчиков вполне может не хватить экспертизы чтобы написать качественный и удобный клиент.
И у меня подгорает с этих вайтишников, которые с трудом могут написать три строки кода для самостоятельной обработки очереди на нативной библитеке от поставщика, так им подавай зачем-то целый фреймворк.
Мне очень понравился ваш тезис и я даже разделяю ваше негодование на тему "вайтишников". Неспособность решить проблему без помощи `pip/npm/whatever install ...` - это боль современного ИТ.
Однако, с остальными вашими тезисами я вынужден не согласиться. Звучит так, будто вы разделяете инструменты только с точки зрения того, как они работают с кодом: "зачем вам эти абстракции, если можно и на клиентах все реализовать?".
Вот только современные инструменты конкурируют не только своим "удобным" API (от которого зависит скорость разработки), надежностью кода и его производительностью. Инструменты конкурируют еще и тем, какой круг задач они позволяют вам решить своим использованием.
Жизненный цикл проекта заключается не только в "написании кода", но и в его тестировании, развертывании, сопровождении и тд. Инструменты, которые закрывают как можно больше число из вышеописанных аспектов - это то, что бизнесу и разработчикам нужно сегодня.
FastStream как раз закрывает потребности не разработчиков по написанию кода, но бизнеса - по всем стадиям развития проекта:
1) Удобный API - написание кода, легче онбординг, дешевле найм и обучение, меньше ошибок на самописных костылях 2) In-Memory тестирование - воспроизводимое поведение, остутствие флакующих тестов, быстрое и безболезненное тестирование в CI 3) AsyncAPI документация - экономим на простоте взаимодействия команд, том же онбординге 4) Готовые рецепты и интеграции для Observability - увеличивает шансы, что кто-то это таки внедрит, что существенно упростит расследование инцидентов, улучшит понимание системы, позволит избежать некоторых аварий
Не случайно в статье всего 1 маленький пример кода - ведь мы говорим не о нем и "абстракциях над абстракциями"
К тому же "абстракции над абстракциями" - это не абсолютное зло. В процессе реализации функционала вашего сервисы вы будете вынуждены написать собственные абстракции, если не берете готовые. Вы уверены, что у вас получится лучше, чем у вендора "готовых абстракций"? Этот вендор скорее всего уже собрал большую часть граблей, которые вы скорее всего прочувствуете на своей шкуре. Просто банально за счет распространенности его проекта и потоку Issues от пользователей, на которые он вынужден реагировать.
Отложенное выполнение "заданий" - это к Celery. Мы ничего не знаем и не делаем с заданиями, мы просто публикуем/потребляем сообщения. Если брокер поддерживает такую фичу на публикацию - то мы тоже ее поддерживаем.
Добрый день! Мы можем завезти max_workers для конкурентного потребления сообщений из одного топика, но только для ack-first политики потребления. Если мы устанавливаем "ручной" commit, то мы не сможем корректно ставить offset, поэтому тут уже нужно скейлится через consumer-group и горизонтально по воркерам
FastStream больше заточен на фичи брокера, чем на "сам себе брокер", так что отлично подойдет для изучения MQ концепций. Да и в половине кейсов вам именно этот функционал нужен, а не Celery.
Это не так. Данный вопрос был имеено в том, что "как сделать так, чтобы на конкуретных воркерах конкретная таска могла работать только в одном экземпляре". Это как раз распределенный лок, о чем я человеку и сказал.
Бродкастинг сообщений по всем экземплярам сервиса - это логика, которую предоставляет брокер, а не фреймворк. В данном конкретном случае Redis Pub/Sub работает именно так. Тут уже нужно разбираться с тем, что вы хотите использовать и получить.
Но насчет отличий FastStream и celery-like инструментов - очень точное замечание. В качестве замены Celery я сам всегда советую взять taskiq
Я просто искал причины аномального роста трафика из РУ сегмента)
А так меня не сложно найти - я во многих чатиках присутствую. А можно даже напрямую меня пинговать по любым вопросам, связанным с брокерами и/или FastStream в чате по фреймворку - https://t.me/python_faststream (мы там еще и фичи всей толпой проектируем)
Ну вообще, такое поведение потому что вы решили взять redis pub/sub в качестве транспорта. Для background тасок я бы предложил лучше взять redis list (если уж очень хочется redis) а еще лучше - NATS JetStream. Но вообще интересно почитать было, как люди используют) Спасибо за статью!
Спасибо за фидбек! Работа над поддержкой множества брокеров в одном приложении есть в планах (как и поддержка ZeroMQ). Можете мониторить прогресс по этому Issue: https://github.com/airtai/faststream/issues/526
Тут больше дело не в починенных докстрингах, а в починенных 'annotations', из которых многие библиотеки как раз понимают, какие аргументы принимает ваша функция. Тот же FastAPI просто перестанет работать, если вы сначала обернете свою функцию без wraps
И насчет
Вложенные декораторы тихо ломаются
В 99.9% случаев как раз ничего и не ломается
Ломаются только очень специфичные кейсы наподобие того, что указан на stackoverflow, однако, решение есть и на этот случай. Которое как раз указал автор в том же топике.
Ну, собственно, в процессе разработки "сложной" библиотеки я к этому и пришел. Но, тем не менее, лучше знать, что такие приемы есть, чем городить костыли, когда возникнет такая необходимость. Я бы не отказался наткнуться на такую статью, пока копался по исходникам разных опенсорсов в попытках найти нормальное рабочее решение. Причем оказалось, что проще сделать его самому.
Я сам столкнулся с тем, что какого-либо "продвинутого" материала по разработке почти нет. Если ты джун - вот тебе "hello world", но если решил сделать что-то дальше, то "ты уже большой мальчик, копай сам".
Поэтому и решил сделать что-то чуть более глубокое, чем обычные забивки в блогах. Тем более опыт и количество набитых шишек позволяет рассказать что-то интересное.
Если такой формат заходит, то скоро будет еще материал про оптимизацию Python кода на уровне синтаксиса (вангую, что сеньоры тоже удивятся некоторым выводам). Ну и разбор фишек 3.12 исходя из практики тоже на подходе.
Мне очень нравятся буллетпоинты, где одно и то же переформулировано несколько раз и выдается под видами "вот вам 5 преимуществ Next JS" + возвращаемся к SEO через каждые 3 слова. Можно, пожалуйста, меньше использовать GPT для генерации материала для блога? Это как минимум неуважительно - люди должны тратить время на прочтение, а вы даже не потратили его на написание/редактуру.
В статье заявлен разбор "всех преимуществ Next", но поговорили только о SSR и SSG (хотя и неплохо для джунов). В общем, пожалуйста, работайте над материалом перед его выкладыванием.
Простите, я снова вынужден с вами спорить
Абстракция может не только "сохранить в лучшем случае", но и приумножить. Например, тот же Celery расширяет функциональные возможности голых брокеров (пряча оригинальные, но мог бы и не делать этого)
Вот вы набрасываете, но не аргументируете. Я спрашиваю - "как вы будете тестировать контракты в асинхронном взаимодействии?". Это не вина разработчика, что он не смог. У него просто нет для этого инструментов
В написанном коде всегда будут ошибки. Не важно, пишете его вы, я или "вайтишник". Если этот код написал разработчик библиотеки, а протестировали его тысячи других пользователей - шанс на ошибку в разы меньше
Кстати, интересное замечание насчет
А вы уверены, что с ними так все хорошо? Давайте пройдемся по ним, чтоли
1) RabbitMQ - тут, слава богу, все хорошо. Есть официальная pika, вот только она синхронная, не везде подойдет. Есть Дмитрий Орлов и его aio-pika - клиент феноменального качества, вот только это обертка над aiormq, который обертка над pamqp.
Какой уровень абстракций вы считаете приемлимым? - Мне не очень понятно
2) Kafka. Ну, тут у нас весело - есть confluent-kafka, которая просто python-биндинги поверх C библиотеки. И падает оно с segfault на каждый чих. Отличная "библиотека от вендора". Есть еще aiokafka - но она же не от вендора, да и не все фичи самой Kafka поддерживает
3) NATS. Еще веселее. nats-py клиент пишет человек из core-команды NATS. Вот только он же пишет и ruby клиент. И язык Python для него не основной. Я нашел МНОГО багов, пока реализовывал поддержку NATS в FastStream поверх этой библиотеки. Часть пофиксили через PR в nats-py, часть получилось обойти на уровне кода. Еще одна прекрасная библиотека от вендора
4) SQS. Тут у нас botocore (синхронный) и aiobotocore (асинхронный) ну и прочие boto3. Это абсолютно непригодные для разработки инструменты, тк банально не имеют ни автокомплитов в IDE, ни проверки типов - это просто классы, которые конструируются в рантайме, поэтому ваш код на момент написания ничего не знает об их поведении
Я не буду продолжать по всем брокерам, просто хочу сказать, что "нативные библиотеки" - это не всегда лучшее решение. В большинстве случаев потом что сам инструмент разрабатывался на одном языке, а клиенты нужны - под все. И у разработчиков вполне может не хватить экспертизы чтобы написать качественный и удобный клиент.
Мне очень понравился ваш тезис и я даже разделяю ваше негодование на тему "вайтишников". Неспособность решить проблему без помощи `pip/npm/whatever install ...` - это боль современного ИТ.
Однако, с остальными вашими тезисами я вынужден не согласиться. Звучит так, будто вы разделяете инструменты только с точки зрения того, как они работают с кодом: "зачем вам эти абстракции, если можно и на клиентах все реализовать?".
Вот только современные инструменты конкурируют не только своим "удобным" API (от которого зависит скорость разработки), надежностью кода и его производительностью. Инструменты конкурируют еще и тем, какой круг задач они позволяют вам решить своим использованием.
Жизненный цикл проекта заключается не только в "написании кода", но и в его тестировании, развертывании, сопровождении и тд. Инструменты, которые закрывают как можно больше число из вышеописанных аспектов - это то, что бизнесу и разработчикам нужно сегодня.
FastStream как раз закрывает потребности не разработчиков по написанию кода, но бизнеса - по всем стадиям развития проекта:
1) Удобный API - написание кода, легче онбординг, дешевле найм и обучение, меньше ошибок на самописных костылях
2) In-Memory тестирование - воспроизводимое поведение, остутствие флакующих тестов, быстрое и безболезненное тестирование в CI
3) AsyncAPI документация - экономим на простоте взаимодействия команд, том же онбординге
4) Готовые рецепты и интеграции для Observability - увеличивает шансы, что кто-то это таки внедрит, что существенно упростит расследование инцидентов, улучшит понимание системы, позволит избежать некоторых аварий
Не случайно в статье всего 1 маленький пример кода - ведь мы говорим не о нем и "абстракциях над абстракциями"
К тому же "абстракции над абстракциями" - это не абсолютное зло. В процессе реализации функционала вашего сервисы вы будете вынуждены написать собственные абстракции, если не берете готовые. Вы уверены, что у вас получится лучше, чем у вендора "готовых абстракций"? Этот вендор скорее всего уже собрал большую часть граблей, которые вы скорее всего прочувствуете на своей шкуре. Просто банально за счет распространенности его проекта и потоку Issues от пользователей, на которые он вынужден реагировать.
Если слушать - то в доке есть пример интеграции. Если публиковать - то есть syncify враппер, который позволяет делать publish из синхронного кода
Отложенное выполнение "заданий" - это к Celery. Мы ничего не знаем и не делаем с заданиями, мы просто публикуем/потребляем сообщения. Если брокер поддерживает такую фичу на публикацию - то мы тоже ее поддерживаем.
Именно)
Зависит от брокера. RMQ, NATS, Redis поддерживают конкуретный consume. С Kafka пока все сложно
Добрый день! Мы можем завезти
max_workersдля конкурентного потребления сообщений из одного топика, но только для ack-first политики потребления. Если мы устанавливаем "ручной" commit, то мы не сможем корректно ставить offset, поэтому тут уже нужно скейлится через consumer-group и горизонтально по воркерамFastStream больше заточен на фичи брокера, чем на "сам себе брокер", так что отлично подойдет для изучения MQ концепций. Да и в половине кейсов вам именно этот функционал нужен, а не Celery.
https://github.com/airtai/faststream
Забавную штуку, кстати, буквально только что нашел - https://github.com/adriangb/asgi-background
Вот это как раз "те самые таски, что в фоне", причем, совместимые с любым ASGI
Ну, дока может говорить о чем угодно, но это не значит, что оно так работает
Вот, например, исходники starlette, в которых явно видно, что таска будет выполнена сразу после записи ответа в asgi (т.е. это обязательный этап запуска handler'а) - https://github.com/encode/starlette/blob/9f16bf5c25e126200701f6e04330864f4a91a898/starlette/responses.py#L161
Это не так. Данный вопрос был имеено в том, что "как сделать так, чтобы на конкуретных воркерах конкретная таска могла работать только в одном экземпляре". Это как раз распределенный лок, о чем я человеку и сказал.
Бродкастинг сообщений по всем экземплярам сервиса - это логика, которую предоставляет брокер, а не фреймворк. В данном конкретном случае Redis Pub/Sub работает именно так. Тут уже нужно разбираться с тем, что вы хотите использовать и получить.
Но насчет отличий FastStream и celery-like инструментов - очень точное замечание. В качестве замены Celery я сам всегда советую взять taskiq
Я просто искал причины аномального роста трафика из РУ сегмента)
А так меня не сложно найти - я во многих чатиках присутствую. А можно даже напрямую меня пинговать по любым вопросам, связанным с брокерами и/или FastStream в чате по фреймворку - https://t.me/python_faststream (мы там еще и фичи всей толпой проектируем)
Ну вообще, такое поведение потому что вы решили взять redis pub/sub в качестве транспорта. Для background тасок я бы предложил лучше взять redis list (если уж очень хочется redis) а еще лучше - NATS JetStream. Но вообще интересно почитать было, как люди используют) Спасибо за статью!
Считаю странным не упоминуть FastStream. Надо потихоньку пропагандировать здоровый образ жизни, а не тащить инструменты 20летней давности.
Спасибо за фидбек! Работа над поддержкой множества брокеров в одном приложении есть в планах (как и поддержка ZeroMQ). Можете мониторить прогресс по этому Issue: https://github.com/airtai/faststream/issues/526
Тут больше дело не в починенных докстрингах, а в починенных 'annotations', из которых многие библиотеки как раз понимают, какие аргументы принимает ваша функция. Тот же FastAPI просто перестанет работать, если вы сначала обернете свою функцию без wraps
И насчет
В 99.9% случаев как раз ничего и не ломается
Ломаются только очень специфичные кейсы наподобие того, что указан на stackoverflow, однако, решение есть и на этот случай. Которое как раз указал автор в том же топике.
Ну, собственно, в процессе разработки "сложной" библиотеки я к этому и пришел. Но, тем не менее, лучше знать, что такие приемы есть, чем городить костыли, когда возникнет такая необходимость. Я бы не отказался наткнуться на такую статью, пока копался по исходникам разных опенсорсов в попытках найти нормальное рабочее решение. Причем оказалось, что проще сделать его самому.
Я сам столкнулся с тем, что какого-либо "продвинутого" материала по разработке почти нет. Если ты джун - вот тебе "hello world", но если решил сделать что-то дальше, то "ты уже большой мальчик, копай сам".
Поэтому и решил сделать что-то чуть более глубокое, чем обычные забивки в блогах. Тем более опыт и количество набитых шишек позволяет рассказать что-то интересное.
Если такой формат заходит, то скоро будет еще материал про оптимизацию Python кода на уровне синтаксиса (вангую, что сеньоры тоже удивятся некоторым выводам). Ну и разбор фишек 3.12 исходя из практики тоже на подходе.