Архитектура FastAPI приложения | Шаблон
Vložit
- čas přidán 28. 01. 2023
- В данном видео вы увидите, как можно легко организовать базовую структуру приложения FastAPI для дальнейшего удобного масштабирования проекта, не упираясь в ограничения архитектуры. Сможете получить удобство навигации по проекту и эффективность в командной разработке
Ссылка на GitHub шаблона - github.com/geekceo/FastAPI-ap...
Спасибо. Отличное видео. Очень хочется увидеть полный проект, который максимально приближен к "боевым" проектам. и связка в базой, брокерами, обработчиками и тд...
Привет, спасибо за фидбек) Готовлю материал для этого видео, в скором времени выложу)
Интересно! Продолжай)
Спасибо, отличный подход!
Спасибо за урок. Прошел с удовольствием
Огромная просба продолжай плиз
Класс, давно искал такой, формат
Круто, отличный ролик!
Благодарю, Отличное видео. Интересно было бы увидеть реализацию авторизации и регистрации через FastAPI-users или другую библиотеку👍
Превосходно
Не много странно, что в описании не указана ссылка на такой шаблон, для более наглядного изучения вне видео. Спасибо за контент)
Привет! Спасибо, что указал на это, добавил в описание. Ссылка - github.com/geekceo/FastAPI-app-Structure-Template
Спасибо за краткое объяснение без лишней воды!
Я так понимаю вы применяете в своём подходе методологию чистой архитектуры?
что -то не получается, жалко нет requirements.txt... A, все, заработало. Спасибо! Супер видео, вернулся спустя время, очень в тему!
Интересно посмотреть на другие архитектуры но я обычно немного другую использую
Привет! Если у тебя есть репозиторий с примером твоей архитектуры, то мог бы ты дать ссылку? Я бы с удовольствием посмотрел)
@@tagirkhalilov8227 я бы тоже)
можно писать просто from .routes import Route
. обозначит текущий каталог
Привет, это обозначает текущий каталог, из которого запущено приложение, поэтому относительных импортов/путей лучше избегать и использовать абсолютные
Какое-то странное стремление всё сделать в ООП стиле, лишнее усложнени
Ох ты тут намудрил а не проще было класический SOA?
Можете создать репозиторий этого шаблона на гитхабе?
Привет! Создал, вот ссылка на репозиторий - github.com/geekceo/FastAPI-app-Structure-Template
Отличное видео! Как сделать себе такие же иконки в ВСе?)))))
Привет! Вот ссылка на расширение для VS Code - marketplace.visualstudio.com/items?itemName=vscode-icons-team.vscode-icons
Для чего это морока с роутами? Есть какой то аргумент в пользу ооп здесь?
Привет! Удобство навигации и заклад на масшатабируемость
@@tagirkhalilov8227 удобство? Масштабируемость? В этих классах наоборот легче запутаться, а что насчет масштабируемости? Фреймворк ты не будешь менять, что будет масштабироваться?
Будут добавляться сопутствующие технологии, orm, базы данных, брокеры сообщений и для взаимодействия со всем этим нужно все правильно разбить по пакетам и модулям. А насчет удобства - мне удобно, когда все лежит на своих полках, когда каждый класс и модуль отвечает за определенное действие. Может кому-то удобно по-другому. В видео я описал свое видение и показал то, что удобно мне, полагая, что поделюсь с другими, кто ищет удобную архитектуру для своих проектов. Я не надеюсь на то, что с этим согласятся все. Мое желание - это поделиться
@@tagirkhalilov8227 а чем фп не угодило? Тоже ведь можно разбить на модули) и каждая функция имеет свою зону ответственности. Ну раз уж так тебе вкусно, то вопросов нет, но как по мне это просто злоупотребление ООП
Несомненно, каждая функция будет иметь свою зону ответственности. Однако на мне лично не удобно читать код, когда все в одном файле. В маленьких проектах можно этого не заметить, а при крупной разработке, а уже тем более в enterprise, когда бизнес-логика часто меняется - это становится, в каком-то смысле, просто невыносимо
Мммм, что-то знакомое
Можно ссылку на оригинальный проект?
У тебя эта ссылка и так есть)
Какие главные сильные стороны у FastAPI?
Привет! Скорость и асинхронность за счет того, что основан на Starlette; поддержка OpenAPI и Swagger, что позволяет быстро генерировать документацию к своему API; расширяемость - есть много плагинов и расширений для FastAPI, поэтому можно легко дополнять встроенные возможности фреймворка и увеличивать функциональность
@@tagirkhalilov8227 спасибо за ответ!
Ужос
Мне понравился гайд, понятно и без воды. Но мне интересно есть ли смысл так усложнять код через такие абстракции с классами. Например подход как тут (гитхаб) AlexDemure/fastapi-architecture выглядит проще и в то же время такой же понятный для командной разработки. Хотелось бы услышать мнение на счет этого
Привет! Спасибо за отзыв) Касательно отличий между подходами в моем видео и в проекте AlexDemure:
1) Пройдясь по структуре проекта AlexDemure можно заметить, что там много пакетов, действительно, в этом нет ничего страшного, ведь проекты могут быть сколько угодно огромными. Тут дело в том, что некоторые из них можно классифицировать по роду назначения и разбить на отдельные родительские пакеты. Именно это я показывал, когда создавал 3 основных пакета и говоря про их назначение. Это намного упростит навигацию по проекту, так как разработчик будет сразу знать, где нужный ему модуль. Это позволит не отвлекаться на поиск среди множества пакетов, находящихся в одной директории.
2) Далее, касательно самой абстракции, в самом определении абстракции дается хороший совет о том, что каждый модуль/класс должен выполнять конкретную задачу и должен быть хорош именно в ней. Если задуматься - то это очень упрощает дальнейшую разработку. Ведь мы всегда знаем какой модуль за что отвечает. Один за инициализацию сервера, второй за регистрацию путей, третий за события. Каждый хорош в своем. Мы всегда знаем в какой модуль залезть для правок и обновлений. В свой подходе AlexDemure старался придерживаться этого, но не везде, из-за этого есть путаница, например в самом модуле main.py в пакете core. Вроде бы у него есть отдельный модуль для регистрации путей, но все равно в модуле main опять происходит регистрация, и описание событий там же, и запуск uvicorn там тоже. Получается сборная солянка и при дальнейшей работе нужно будет думать и искать - а где же я оставил события, какая из регистраций путей нужна мне сейчас? В файле urls.py или которую я в main писал?
В подходе, который описан в видео такой путаницы быть не может, так как каждый пакет отвечает за конкретные модули, связанные "родом деятельности", и каждый модуль выполняет ровно одну свою задачу.
Свой подход я выработал на основе именно коммерческой разработки, где так же сталкивался с разным описанием архитектуры приложения разной степени эффективности и удобства. В конце концов подытожил все в такой вид, о котором говорил и показывал в видео)