Идеи по улучшению API

[b7w]

Когда на habr увидел первую версию propan, решил не комментировать. Ибо уже все написано. Но раз сейчас планируется мажорная смена версии, решил донести пару идей.

1. Дать возможность регистрировать обработчики без декораторов

broker.register_handler('test-queue', handler_func)
broker.register_handler('test-queue-2', handler_func2)

Декораторы это удобно когда все в одном файле и проект маленький. Но когда проект разрастается. хочется иметь обработчики отдельно от конфигурации, и не хочется тащить зависимость на app/broker в пакет с логикой.

2. Большая связанность в обработчиках/брокерах/названия топиков

Грубо говоря сейчас декоратор привязывает обработчик к конкретному брокеру и топику, что кажется не очень чистым кодом. И к примеру без переписывания кода нельзя поменять топик на тестовом стенде.
У нас в проектах в итоге все обрастает колхозными настройками

Предлагаю обратить внимание на описание подключений и настроек в виде конфига, а в коде ссылаться на alias.
Мне кажется хороший пример есть в helidon framework - https://helidon.io/docs/v3/#/mp/reactivemessaging/kafka

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

Возможно с этим подходом можно будет убрать зависимость на ссылку broker в after_startup:

@app.after_startup
async def test_publishing():
    await app.broker('alise').publish('Hello!', 'test-queue')

3. Еще раз про dependency injection

В ваших примерах after_startup есть ссылка на app и broker - внешние зависимости. Лучше давать framework'ку управлять зависимостями, пуcть каждый обработчик получает первым аргументом app или broker. А прикладной код не знает где и когда был создан объект app/broker.

@app.after_startup
async def test_publishing(app):
    await app.broker('alise').publish('Hello!', 'test-queue')

[Lancetnik]

@b7w Добрый день! Спасибо за подробные комментарии.
По поводу необходимости получать доступ к объектам app и broker через замыкания: сейчас такой необходимости нет. Вы можете получить доступ к ним через Context примерно следующим образом:

from propan.annotations import App, RabbitBroker

@app.after_startup
async def hook(app: App, broker: RabbitBroker):
    ...

Как видите, никаких замыканий.

По поводу описания конфигов и названий топиков в виде алиасов внутри приложения. Если честно, мне очень не нравится эта идея: зачем хранить инициализацию всех алиасов в коде, если использоваться в итоге будет только одна? Тем более такой подход существенно усложняет публичный API фреймворка

 app.broker('alise').publish('Hello!', 'test-queue')

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

Вместо предложенного вами подхода я прямо сейчас храню все названия топиков и данные для подключения в pydantic_settings и переключанию различные сетапы просто через разные .env файлы: поменял файл при запуске - поменялись все топики и данные для подключения. В тестах аналогично, просто выбор файла осуществляется исходя из переменной окружения.

По поводу отложенной регистрации: она присутствует и сейчас.

from propan import RabbitBroker

async def handler(msg): ...

broker = RabbitBroker()

broker.handle("test-queue")(handler)

Может быть, это и не самый интуитивный интерфейс, но он работает.
Возможно, если бы вы обратились ко мне за консультацией о том, как готовить Propan, получилось бы избежать

У нас в проектах в итоге все обрастает колхозными настройками

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

решил не комментировать. Ибо уже все написано

Anyway, я подумаю над вашими предложениями, возможно, что-то из них найдет себе место в новой версии.

[b7w]

Про колхоз это боль с работы с больших java spring проектов, где тоже нет единого подхода к конфигурации и начинаются проблемы. Особенно у не опытных. А у вас была озвучена идея а давай отдадим нашему стажеру сервис, он по документации разберется, поэтому и решил что стоит тут тоже стандартизировать и унифицировать. И вы вырно заметилил, не обязательно конфиги. Можно сделать что бы в коде была dict обший, а как его получат - дело конкретных людей.

[b7w]

Я понимаю что можно декоратор вызвать напрямую broker.handle("test-queue")(handler), но выглядит это всегда шокирующе. И вроде не сложно добавить явный метод.

[Lancetnik]

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

[b7w]

Я понимаю что почти все можно решить, хотелось поделиться именно идеями основанными на опыте

[Lancetnik]

Да, спасибо, собственно от вас я и узнал, что есть такая потребность

[Lancetnik]

Кстати, да, в новой версии планируется поддержка множества брокеров в рамках одного PropanApp. Возможно, хранение их в виде dict имеет смысл, так что да, вы сможете получать доступ к разным брокерам по ключу (или "алису", если угодно)

[Lancetnik]

@b7w я просто не хочу вмешиваться в то, как пользователи управляют настройками проекта чтобы не ограничивать их в этом. Именно такого подхода и придерживаются все фреймворки (за исключением разве что Django).

Однако, если у вас возникают какие-то проблемы с этим, вот пример того, как это делаю я в своих проектах:

import os
from pydantic_settings import BaseSettings
from pydantic import Field

from propan import PropanApp
from propan.rabbit import RabbitBroker

class Settings(BaseSettings):
    url: str = Field(...)
    queue: str = "test-queue"

settings = Settings(_env_file=os.getenv("ENV", ".env"))

broker = RabbitBroker(settings.url)
app = PropanApp(broker)

@broker.handle(settings.queue)
async def handler(msg):
    ...

# ENV=.prod.env propan run serve:app
# ENV=.test.env pytest
# ...

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

[b7w]

Возможно вам в документации стоит упомянуть как "кананично" можно делать настройки. Уверен что для многих это будет полезно.

[Lancetnik]

Собственно, добавил https://lancetnik.github.io/Propan/getting_started/10_settings/

[pikhovkin]

Вы рассматривали Dynaconf для управления настройками?

[Lancetnik]

Нет, я не рассматривал библиотеку Х для управления настройками. Управление настройками не является частью проекта, вы можете использовать инструмент, который удобен вам. В документации я даю только пример.

[b7w]

Вы рассматривали Dynaconf для управления настройками?
День добрый! Впервые вижу, обязательно посмотрю. Спасибо!

[Lancetnik]

@b7w By the way, про проблемы, с которыми столкнулись, вы написали
А в целом каков ваш опыт от использования фреймворка?

[b7w]

Сильно похвастаться не могу, пока только протетипирования для своих нужд.

[Lancetnik]

@b7w что думаете насчет подобного синтаксиса?
https://github.com/Lancetnik/Propan/blob/v2/examples/router/03_delay_registration.py#L11

[b7w]

Выглядит многословно, как будто то срарой java повеяло :-)