FastOpenAPI: автодокументация OpenAPI для разных фреймворков на Python

Неплохо, есть какие-либо планы по поддержки AsyncAPI?

Код свободы: Хабр и GitVerse открывают сезон Open source

Опа, в таком мы участвуем

Фоновые асинхронные задачи в FastAPI и их мониторинг

Как в итоге ваши эксперименты с FastStream?)

Наш архитектурный подход к Python приложениям

Если ты под "доменными объектами" имеешь в виду модельки алхимии, то все так и есть, как ты описал.

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

Наш архитектурный подход к Python приложениям

Ну, я в принципе против того, чтобы у нас был глобальный объект `from app.settings import settings`, который можно импортнуть в любом месте кода - потом очень сложно следить, какое поле конфига где используется.

Запутанные конфиги с алиасами тоже как будто не упрошают восприятие кода. Если же юзать только один алиас для всего приложения целиком - то никакой проблемы не вижу

Наш архитектурный подход к Python приложениям

Например, вот тот же конфиг, но без лишних зависимостей

class ServiceSettings(BaseModel):
    service_name: str = "micro-service",
    service_description: str = "Micro service description"

    database_url: str = "your-database-url"
    database_read_timeout: int = 5

    redis_url: str = "your-redis-url"

    ...


settings = ServiceSettings(**os.environ)

Наш архитектурный подход к Python приложениям

У нас этот «паттерн» работает хорошо. Ты всегда знаешь, что в project_name лежит settings.py из которого ты достаешь глобальный объект с настройками, которые могут потребляться из любого окружения. Чем это хорошо:

— унифицировано

— наглядно

— просто

И вот эти все плюсы достижимы и без pydantic_settings, вот и все

Наш архитектурный подход к Python приложениям

Смотри, как могу Settings(**os.environ) - https://github.com/MultiDirectoryLab/MultiDirectory/pull/489/files

Наш архитектурный подход к Python приложениям

Отлично, тогда снова возникает вопрос, какую пользу несет pydantic_settings[dotenv], если можно обойтись просто без этих двух зависимостей?

Наш архитектурный подход к Python приложениям

Не очень понял использование репозиториев AdvancedAlchemy

class PostRepository(SQLAlchemyAsyncRepository[Post]):
    """Repository for managing blog posts."""
    model_type = Post

    # уже реализовано в родительском классе репозитория
    async def add(...)
    async def add_many(...)
    async def list(...)
    async def update(...)
    async def delete(...)
    ...

Репозиторий должен возрващать доменные объекты приложения, полностью инкапсулируя модели алхимии внутри себя. Если я не путаю, AdvancedAlchemy репозиторий отдает в качестве ответов модели алхимии.

Если вы делаете свои надстройки над SQLAlchemyAsyncRepository, то тема с заворачиванием ее результата в доменные объекты не раскрыта. Опять же - там очень примитивная логика внутри. Если мы наследуемся от этих generic репозиториев, то какую пользу мы вообще получаем? Не проще реализовать репу с 0?

Наш архитектурный подход к Python приложениям

Пример с глобальным объектом settings, который еще и сам читает переменные окружения выглядит ну уж слишком сомнительно в вакууме

class ServiceSettings(pydantic_settings.BaseSettings):
    service_name: str = "micro-service",
    service_description: str = "Micro service description"

    database_url: str = "your-database-url"
    database_read_timeout: int = 5

    redis_url: str = "your-redis-url"

    ...

    # используется, чтобы загружать переменные из файла .env
    model_config = pydantic_settings.SettingsConfigDict(
        env_file=".env",
        env_file_encoding="utf-8",
        populate_by_name=True,
    )

settings = ServiceSettings()

Как вы в реальных проектах переключаете .env файлы под разные окружения? Как настраиваете окружение на проде, где .env файла просто нет (или у вас есть)?

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

ООП: худшее, что случалось с программированием

Какой-то треш... Автор не понимает ни концепции ООП, ни ФП, зато понимает TypeScript и ловко владеет всеми возможными способами прострелить себе колени

FastAPI и Dependency Injection: правда или вымысел?

Нет, dishka inject - это декоратор под конкретный фреймворк и работает только в контроллере. Во всех остальных частях кода вам остается таскать контейнер явным образом и делать "container.get(T)" для получения зависимостей. Или писать свой inject-декоратор. Однако, это не рекомендуется делать, о чем я в статье вскольз предупреждаю.

FastAPI и Dependency Injection: правда или вымысел?

Никто не планирует сроки поддержки библиотеки. Поэтому и нужно "сообщество" и круг мейнтейнеров, а не один человек. Bus factor никто не отменял. В жзни всякое может случиться и мейнтейнер может пропасть.
Яркие примеры - rocketry, faust. Но тот же Faust подхватило "сообщество", сделало форк и развивает дальше.
В этом у dishka тоже есть плюс, т.к. он входит в небольшую, но все-таки организацию энтузиастов, над проектом работает сразу несколько вовлеченных контрибуторов, и флаг есть кому подхватить

FastAPI и Dependency Injection: правда или вымысел?

Согласен, тут имеет место быть небольшое смешение понятий. Для меня DI неразрывен от DIP, т.к. без него он приносит только половину пользы. Вторую половину я и хотел показать в статье.

FastAPI и Dependency Injection: правда или вымысел?

Ну, то, что он мой - не значит, что он самый-самый). FastDepends - это буквально копия API FastAPI и он грешит теми же проблемами в качестве DI

Но он решает несколько другую проблему, нежели просто DI и нужен он мне именно в таком виде. Все-таки в качестве чистого IoC контейнера dishka значительно лучше.

FastAPI и Dependency Injection: правда или вымысел?

Используйте запуск через uvicorn или любой другой ASGI сервер вместо FastAPI CLI

FastAPI и Dependency Injection: правда или вымысел?

Ну ничего себе, действительно ожил. Однако, 1 коммит раз в месяц - это не прям "активное развитие". На самом деле, я не против Dependency Injector, просто он очень сильно перегружен, реализация на глобалах и вроде как не thread-safe

FastAPI + Redis + Celery: Создание системы временного хранения файлов с автоудалением и удобным веб-интерфейсом

Подписался на обоих) Спасибо за материал!

FastAPI + Redis + Celery: Создание системы временного хранения файлов с автоудалением и удобным веб-интерфейсом

У меня уже глаз дергается от сочетания FastAPI + Celery, но тут он вполне уместен. Отличная работа! Btw, не пробовали сочетание FastAPI + FastStream - интересны ваши мысли на этот счет