MoscowPython Meetup 80. Как мы с Fastapi на Django перешли 

иногда это быстрее)

@@mcaq1 быстрее чем что? типа если что-то болит вы таблетки просто перебираете всякие разные? ну вот команда например быстро за месяц перепишет. а проблема не решена и что тогда?

Ага, просто рука-лицо. Мда... А раньше в 64кб графические редакторы умещали, были времена... Печалька. Досмотрел до этого момента, дальше не стал.

Тем не менее интересно посмотреть как работают другие команды. Раз не было компетенций быстро разобраться значит приняли честное и правильное с точки зрения бизнеса решение. И чел не постеснялся в докладе рассказать как все было

Видимо команде прототипирования надоело писать всё на Джанго и захотелось разнообразия)

@@yodapunishes скорее всего. у команды просто видимо хватает времени на все эти девелоперские развлечения.

хайлоад и фастапи это разные вещи. ИЛи вы последователь асинхронность = скорость = круто? Если грамотно работать с джанго орм и норм настроить воркеров - джанга будет совсем чуть хуже фастапи при условии приложения-круда

@@agentdaun5699 Джанго и хайлоад это разные вещи :) Асинхронность просто io bound без заморозки главного потока. fastapi/litestar это просто удобный способ rest api с типизацией и dto. Джанго когда нужна админка.

я вообще не понимаю прикола с повторением дто с модельками) это же работает до того, пока у тебя проект маленький, ведь структура БД определяется удобством, а поля в ДТО определяются бизнес-логикой

@@Fartek2 что значится структура БД определяется удобством? имхо всегда исходил из того что надо ориентироваться на задачи

@@AlexKrundetz У меня сейчас на проекте нет Output ДТО(схем, представлений) и напрямую в контроллеры светим модельками алхимии, а потом фастапи пусть сам сериализует. Из-за этого моделька превратилась в хаос из property/property.setter(python, setter/getter если на другие языки), а изначально не казалось что будут проблемы

Аналогично😂😂

Да ладно select(1) тоже норм, ну небольшой костылик, зато модно молодежно

Если нужно качество, то брать именно разработчика на джанго, а не любого питониста. Иначе будет трэш в коде. Я сейчас очень сильно огребаю от старших за свой "wrong Django way" подход. Сочувствую коллегам, которые со мной возятся и спасибо им, что не бросают.

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

У кого как. Клиентские проекты живут и каши не просят. Ровно до момента, пока не потребуется кардинально менять логику. Но там так и так заново переписывать. Так что ни какой разницы нет.

pgbouncer приколбасить

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

Полагаю, что им именно 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.

джанго приучил не вручную 😂

@@knowledgedose1956 алембик может самм генерировать миграции. Т.е. поменяли модель бд, он сгенерировал миграцию. Но лучше это делать вручную. Может мне так привычнее. Спрашивал коллег, давно работающих в компаниях. Только один делает на автомате ) Конечно, это не отменяет проверку миграции на локальной БД, перед коннитом

тоже смутил этот момент

Что ужасного в архитектуре джанги? Кроме момента с сериализаторами

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

@@antonperelygin2833 отсутствие явного слоя бизнес логики, которая может быть размазана по сериализаторам, моделям и вьюхам. Многие выкручиваются всякими logic и services уровнями, что никак не контролируются фреймворком

@@user-op5sw7zm2s а где есть явный слой бизнес-логики?

@@user-op5sw7zm2s 1. Что плохого в написании простой бизнес-логики во вьюхах? Они же по факту роль контроллеров исполняют, почему это плохо? Я не говорю про кейсы с большим кол-вом кода, который действительно удобнее вынести в services/selectors/etc, но этого же никто делать и не запрещает. 2. Зачем размазывать логику по моделям? Fat models это в целом не совсем здоровый подход, но разве условные property доставляют какую-то особенную боль, особенно если туда не писать саму бизнес-логику, а простую дефолтную работу с типами/преобразованиями/etc?

начальник. именно что не писатель скорее всего.