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

я бы и не заметил, если бы не комент лол

Привет, вот это расширение для VCS marketplace.visualstudio.com/items?itemName=garytyler.darcula-pycharm

Привет! Очень загружен работой, очень надеюсь, что в ближайшие пару дней успею отснять и загрузить материал)

@@tagirkhalilov8227 Круто, понимая сам загружен. Продолжай в том же духе, мне очень понравился твой подход к архитектуре.

Привет! Скорость и асинхронность за счет того, что основан на Starlette; поддержка OpenAPI и Swagger, что позволяет быстро генерировать документацию к своему API; расширяемость - есть много плагинов и расширений для FastAPI, поэтому можно легко дополнять встроенные возможности фреймворка и увеличивать функциональность

@@tagirkhalilov8227 спасибо за ответ!

Привет! Да, будет, сейчас собираю материалы для следующего ролика

Привет! Вот ссылка на расширение для VS Code - marketplace.visualstudio.com/items?itemName=vscode-icons-team.vscode-icons

Нужно ответное видео "что не так" я бы глянул

У вас есть репозиторий с примером FastApi проекта? Я бы глянул. Без негатива, посмотрел бы как лучше делать.

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

Привет! Воспользовавшись API Binance для получения списка всех пар, можно при помощи pydantic преобразовать полученный JSON в список словарей, а далее воспользовавшись функцией filter() получать данные нужной пары, например: list(filter(lambda currency: currency['symbol'] == 'BTCUSDT', currencyList)) Где curencyList - это список словарей, полученный из JSON Этот однострочник вернет такой ответ: [{'symbol': 'BTCUSDT', 'price': '23681.28000000'}]

@@tagirkhalilov8227 понял спасибо)

Привет! Рад, что видео было интересным для вас)

Привет! Но тем не менее в таких базовых примерах создания запланированных задач fastapi utils все ещё работает

@@tagirkhalilov8227 ну такое, я бы не использовал такие библиотеки, у fastapi быстрый цикл разработки, это не джанго с дооолгими LTS. Как альтернатива - это портировать небольшими кусками в утилиты самому

У тебя эта ссылка и так есть)

Привет! Удобство навигации и заклад на масшатабируемость

@@tagirkhalilov8227 удобство? Масштабируемость? В этих классах наоборот легче запутаться, а что насчет масштабируемости? Фреймворк ты не будешь менять, что будет масштабироваться?

Будут добавляться сопутствующие технологии, orm, базы данных, брокеры сообщений и для взаимодействия со всем этим нужно все правильно разбить по пакетам и модулям. А насчет удобства - мне удобно, когда все лежит на своих полках, когда каждый класс и модуль отвечает за определенное действие. Может кому-то удобно по-другому. В видео я описал свое видение и показал то, что удобно мне, полагая, что поделюсь с другими, кто ищет удобную архитектуру для своих проектов. Я не надеюсь на то, что с этим согласятся все. Мое желание - это поделиться

@@tagirkhalilov8227 а чем фп не угодило? Тоже ведь можно разбить на модули) и каждая функция имеет свою зону ответственности. Ну раз уж так тебе вкусно, то вопросов нет, но как по мне это просто злоупотребление ООП

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

Привет! Если у тебя есть репозиторий с примером твоей архитектуры, то мог бы ты дать ссылку? Я бы с удовольствием посмотрел)

@@tagirkhalilov8227 я бы тоже)

Привет! Да, насчёт events ты все верно понял. А init файлы используют в основном для удобства импортирования, но они предоставляют гораздо больше возможностей, например, пара из них: 1) Указание магического поля ___all___ для удобства импортивания модулей пакета через * 2) Проверка зависимостей перед использованием пакета Насчёт __routes__ - это не магический атрибут, нижнее подчёркивание по бокам - это лишь синтактический сахар) Да и у магических методов/атрибутов - по 2 подчеркивания по бокам, а тут одно

@@tagirkhalilov8227Спасибо за развернутый ответ!

Привет! Спасибо за фидбек) Вот ссылка на репозиторий - github.com/geekceo/FastAPI-app-Redis-Docker Если вдруг не поможет, то отпиши под этим комментом, свяжемся в тг и я помогу тебе

@@tagirkhalilov8227 всё ок уже, какая-то странная ерунда была с os.getenv(..) Спасибо за репозиторий!!! Давай больше видео, давай еще подконнектим sqlalchemy асинхронный и вообще эндпоинты асинхронные) Чтоб всё по красоте) И еще RabbitMQ / Celery а затем CI/CD вот это будет самый нужный стек игрушек)

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

Привет! Спасибо, что указал на это, добавил в описание. Ссылка - github.com/geekceo/FastAPI-app-Structure-Template

Привет! Создал, вот ссылка на репозиторий - github.com/geekceo/FastAPI-app-Structure-Template

Привет, спасибо за фидбек) Готовлю материал для этого видео, в скором времени выложу)

Привет! Спасибо за отзыв) Касательно отличий между подходами в моем видео и в проекте AlexDemure: 1) Пройдясь по структуре проекта AlexDemure можно заметить, что там много пакетов, действительно, в этом нет ничего страшного, ведь проекты могут быть сколько угодно огромными. Тут дело в том, что некоторые из них можно классифицировать по роду назначения и разбить на отдельные родительские пакеты. Именно это я показывал, когда создавал 3 основных пакета и говоря про их назначение. Это намного упростит навигацию по проекту, так как разработчик будет сразу знать, где нужный ему модуль. Это позволит не отвлекаться на поиск среди множества пакетов, находящихся в одной директории. 2) Далее, касательно самой абстракции, в самом определении абстракции дается хороший совет о том, что каждый модуль/класс должен выполнять конкретную задачу и должен быть хорош именно в ней. Если задуматься - то это очень упрощает дальнейшую разработку. Ведь мы всегда знаем какой модуль за что отвечает. Один за инициализацию сервера, второй за регистрацию путей, третий за события. Каждый хорош в своем. Мы всегда знаем в какой модуль залезть для правок и обновлений. В свой подходе AlexDemure старался придерживаться этого, но не везде, из-за этого есть путаница, например в самом модуле main.py в пакете core. Вроде бы у него есть отдельный модуль для регистрации путей, но все равно в модуле main опять происходит регистрация, и описание событий там же, и запуск uvicorn там тоже. Получается сборная солянка и при дальнейшей работе нужно будет думать и искать - а где же я оставил события, какая из регистраций путей нужна мне сейчас? В файле urls.py или которую я в main писал? В подходе, который описан в видео такой путаницы быть не может, так как каждый пакет отвечает за конкретные модули, связанные "родом деятельности", и каждый модуль выполняет ровно одну свою задачу. Свой подход я выработал на основе именно коммерческой разработки, где так же сталкивался с разным описанием архитектуры приложения разной степени эффективности и удобства. В конце концов подытожил все в такой вид, о котором говорил и показывал в видео)