MoscowPython Meetup 80. Как мы с Fastapi на Django перешли
HTML-код
- Опубликовано: 11 фев 2023
- Александр Шишенко (ПГК Digital, Руководитель группы разработки).
Мы переписали бекенд с FastAPI на Django. Расскажу, почему и как нам пришло это в голову, и что из этого получилось.
Слайды: moscowpython.ru/meetup/80/fas...
MoscowPython: moscowpython.ru
Курсы Learn Python: learn.python.ru
Moscow Python Podcast: podcast.python.ru 
Наука
Непонятно где проблема в данном случае. В fastapi или в неумении его готовить и работать с микрофреймворками.
Отрицание, торг, депрессия, Django 😂
Вместо того чтобы разобраться почему теряется соединение с бд лучше переписать на другой фреймворк. Отличный план
иногда это быстрее)
@@mcaq1 быстрее чем что? типа если что-то болит вы таблетки просто перебираете всякие разные? ну вот команда например быстро за месяц перепишет. а проблема не решена и что тогда?
Ага, просто рука-лицо. Мда... А раньше в 64кб графические редакторы умещали, были времена... Печалька. Досмотрел до этого момента, дальше не стал.
Тем не менее интересно посмотреть как работают другие команды. Раз не было компетенций быстро разобраться значит приняли честное и правильное с точки зрения бизнеса решение. И чел не постеснялся в докладе рассказать как все было
"Зумеры поняли, что прежде всего это решение задач бизнеса"
Спасибо тебе добрый человек за лекцию!
Спасибо за видео👍
Спасибо, было интересно
Любой доклад по теме Python как бальзам на душу. Спасибо
Народу нравится. Улыбки на лицах😊
В англоязычных ресурсах читал истории ухода с FastApi в том числе и на Flask - как раз по причине гибкости архитектуры, переноса кода и большого количества сторонних батареек для фласка. Сложилось впечатление, что у них фласк куда более популярен, чем у нас. И многие там не считают фастапи его заменителем.
Понятно, что в случае с джанго куда меньше проблем с качеством/совместимостью батареек, да и под описанную задачу джанга хорошо подходит. Но, конечно, был бы интересен и обзор экосистемы фласка под такие задачи.
p.s. так и не разобрались, в чём была проблема с алхимией? Сложилось впечатление, что если бы такой проблемы не было, всё могло бы пойти иначе :)
душевненько)
спс поржал
Почему не рассказали за Piccolo ORM 😢😢
Честно говоря, в команде прототипирования приняли странное решение делать прототип на молодом микрофреймворке к которому надо прикладывать много рукопашества, а не на инструменте, который заточен под быстрое развертывание прототипов ибо всё есть в комплекте.
Вроде ж общеизвестная тема - если нужен MVP, то берёшь Django или RoR, и выкатываешь в прод спустя минимум времени, не тратя сил на велосипедостроение :) А потом уже думаешь, как с этим жить дальше))
Видимо команде прототипирования надоело писать всё на Джанго и захотелось разнообразия)
@@yodapunishes скорее всего. у команды просто видимо хватает времени на все эти девелоперские развлечения.
Алхимия 2.0 - асинхронна
гибридные поля и методы
Да, нужно описывать схемы и модели.
Схемы поддерживают наследования. Вы одну схему используется для обновления, другую для создания и т.д.
Модели алхимии - миксины и наследования.
Алхимия тяжела тем что позволяет прям всё что угодно настраивать. Изза этого, там документация огромная, изучать долго
я вообще не понимаю прикола с повторением дто с модельками) это же работает до того, пока у тебя проект маленький, ведь структура БД определяется удобством, а поля в ДТО определяются бизнес-логикой
@@Fartek2 что значится структура БД определяется удобством? имхо всегда исходил из того что надо ориентироваться на задачи
@@AlexKrundetz У меня сейчас на проекте нет Output ДТО(схем, представлений) и напрямую в контроллеры светим модельками алхимии, а потом фастапи пусть сам сериализует. Из-за этого моделька превратилась в хаос из property/property.setter(python, setter/getter если на другие языки), а изначально не казалось что будут проблемы
Если сервис не хайлоад, то джанго это первое, что должно было прийти в голову разрабам, учитывая требования 😀
хайлоад и фастапи это разные вещи. ИЛи вы последователь асинхронность = скорость = круто?
Если грамотно работать с джанго орм и норм настроить воркеров - джанга будет совсем чуть хуже фастапи при условии приложения-круда
@@agentdaun5699
Джанго и хайлоад это разные вещи :)
Асинхронность просто io bound без заморозки главного потока.
fastapi/litestar это просто удобный способ rest api с типизацией и dto.
Джанго когда нужна админка.
в алхимии есть параметр ping и не надо делать select 1 перед каждым запросом.
Да ладно select(1) тоже норм, ну небольшой костылик, зато модно молодежно
разработчика на джанго надо искать именно как разработчика на джанго, просто знающий питон не сойдёт?
Если нужно качество, то брать именно разработчика на джанго, а не любого питониста. Иначе будет трэш в коде. Я сейчас очень сильно огребаю от старших за свой "wrong Django way" подход. Сочувствую коллегам, которые со мной возятся и спасибо им, что не бросают.
Доклад отличный, видно что спикер в теме
8:27 ну ё-моё, вот и разорвали бы этот замкнутый круг своим примером. И что же теперь, с алхимией вечно жить и не смотреть по сторонам?
в целом удобна, но админка под неё ужасная, та самая, про которую он дальше говорит, что есть платные фичи. админка недопилена, приходится исправлять баги, пилить с нуля части страниц, части таблиц и тд. это часто стопор, особенно если надо быстро, или люди не любят мазохизм, и особенно если новички, есть большое искушение спрыгнуть на Джанго с её админкой
Ютуб мысли читает похоже... только я таки решил стартануть проект не на джанго, а пошел по модному пути FastApi, SQLModel, SQLAdmin и вуаля, мне рекомендуется это видео 😁
Аналогично😂😂
Так джанга тоже синхронная. Можете хоть сколько там asgi поднимать, но какой в этом смысл, если orm синхронная?
А везде вот так асинхронность нужна ? Особенно в бизнес логике, где большинство задач - это куча последовательных друг от друга зависящих действий.
Полагаю, что им именно channels зашел, а у фласка прям такового качественного аналога не встречал.
с 4.1 ORM поддерживает асинхронность
Уже тоже асинхронная.
@@trankov Нет, пока только частично асинхронная. Here's a list of some of the Django ORM features that are currently fully async in Django 4.1:
Querying with filter(), exclude(), annotate(), order_by(), and other query-set methods using async for loop syntax.
Retrieving single objects using the get() method with await.
Creating new objects using the create() method with await.
Updating objects using the update() method with await.
Deleting objects using the delete() method with await.
Counting objects using the count() method with await.
Aggregating values using the aggregate() method with await.
Performing subqueries using Subquery and OuterRef.
Prefetching related objects using prefetch_related() and select_related().
And here are some ORM features that are not yet fully async in Django 4.1:
Transactions using @transaction.atomic.
Many-to-many relationships using the add(), remove(), and set() methods.
Some advanced query features, such as complex Q() objects and conditional expressions.
Some specialized ORM functions, such as bulk_create() and bulk_update().
Some contrib packages, such as django.contrib.auth.
Корректность использования коннектов к бд проверяется нагрузочным тестированием до выкатки на прод. Предполагаю, что пуллинг бы решил вашу проблему.
Монолитную же архитектуру можно делать на любом фреймворке с орм или без него.
По моему мнению минусов у джанги с ее орм больше, чем плюсов. Для проектов, которые хотят жить больше года*
У кого как. Клиентские проекты живут и каши не просят. Ровно до момента, пока не потребуется кардинально менять логику. Но там так и так заново переписывать. Так что ни какой разницы нет.
pgbouncer приколбасить
С какого перепугу алембик только с алхимией работает?
Если вручную миграции писать, то можно с любым ОРМ.
Лучше вручную миграции писать. Контроля больше. Меньше шансов потерять данные
Пару лет назад делал хомяка. Сделал апи на фастапи и вронт на VUE. Чем же вронт раздавать. Да на том же фастапи. Так и работало, приложение на фастапи и рест апи и статику отдавал.
джанго приучил не вручную 😂
@@knowledgedose1956 алембик может самм генерировать миграции. Т.е. поменяли модель бд, он сгенерировал миграцию. Но лучше это делать вручную. Может мне так привычнее. Спрашивал коллег, давно работающих в компаниях. Только один делает на автомате )
Конечно, это не отменяет проверку миграции на локальной БД, перед коннитом
Суть доклада: я не умею в фастапи, по этому будем писать на джанго
5:40 а в джанге не нужно описывать модели по два раза? Типо сериалайзеры это другое?
Те же самые датаклассы, только навороченные
тоже смутил этот момент
превосходство подтверждения
Есть спорные вещи. Например, про то, что в связке алхимии и фаст апи приходится писать и модели, и pydantic схемы. Так-то оно так. Но ведь от этого вы никуда никогда не уйдете. Разница в том, что в drf вы будете писать сериализаторы, чтобы парсить и валидировать модели. Тот же хрен, только в профиль. И даже если вы думаете что с помощью SQLModel вы уйдете от этого, то нет. Вам все равно нужно будет делать отдельные схемы для создания и представления моделей. Более того, я наоборот ушел назад с sqlmodel в алхимию, так мне кажется правильнее, когда модели и схемы сериализации/валидации представлены разными сущностями.
Опять же, у джанги отвратительная архитектура. Особенно если вы юзаете не базовые сущности, а всякие надстройки. Запись в бд из сериализатора - да пожалуйста! ДРУГОЕ ДЕЛО! Если вы делаете прототип или даже mvp то джанга вполне себе норм, так как тупо быстро накидывается и даже работает.
Собственно на этом и можно было заканчивать доклад.
Что ужасного в архитектуре джанги? Кроме момента с сериализаторами
@@antonperelygin2833 такие моменты сплошь и рядом, даже вьюшки-дженерики у дрф лезут в базу под капотом, менеджеры моделей засунуты внутрь самих моделей Конечно, это все решается тем, что ты берешь базовый класс и прописываешь все сам, создаешь отдельный сервисный слой, отдельный слой репозиториев, и все становится более-менее вменяемым, но ведь Джангу как раз и любят за подкапотную магию.
@@antonperelygin2833 отсутствие явного слоя бизнес логики, которая может быть размазана по сериализаторам, моделям и вьюхам. Многие выкручиваются всякими logic и services уровнями, что никак не контролируются фреймворком
@@user-op5sw7zm2s а где есть явный слой бизнес-логики?
@@user-op5sw7zm2s 1. Что плохого в написании простой бизнес-логики во вьюхах? Они же по факту роль контроллеров исполняют, почему это плохо? Я не говорю про кейсы с большим кол-вом кода, который действительно удобнее вынести в services/selectors/etc, но этого же никто делать и не запрещает.
2. Зачем размазывать логику по моделям? Fat models это в целом не совсем здоровый подход, но разве условные property доставляют какую-то особенную боль, особенно если туда не писать саму бизнес-логику, а простую дефолтную работу с типами/преобразованиями/etc?
Вешаешь Django Ninja вместо DRF и живёшь как боженька. Тем более Django 4.1+ полностью асинхронный.
Смотрел, как этот товарищ переходил с плюсов на раст. А тут уже с фреймворков питона переходит. Чукча - не читатель, чукча - писатель?
начальник. именно что не писатель скорее всего.
це ржака лупанути кучу бабла щоб перейти на іншу систему, але перейшли на залупу)
Ну вот еще одно подверждение что на питоне обычно клоуны пишут ...