Вхід і реєстрація
Розробка · 11 вересня 2022, 10:47 2720
Oleh Smolynets

Про популярність Django. Чи є перспективи?

Всім привіт! Цікавить таке питання. Я років три працював на проектах тільки з джанго, зараз працюю з фласком, але він мені не дуже подобається. Планую в майбутньому фокусуватися на джанго проектах. Але чи має джанго в майбутньому перспективу, чи далі вона часто буде використовуватися для нових проектів? Чи все-таки flask/fastapi будуть її витісняти? Тобто, чи будуть моноліти в майбутньому більш популярні ніж мікросервіси в веб розробці на пайтон?
Можливо для когось це прозвучить надто тривіально, але все ж цікавить думка більш досвідчених людей)

Теми: Django, flask, Python, tech
👍ПодобаєтьсяСподобалось2
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Алексей Степаненко Web Development, Python, Django 27.09.2022 13:38

Фпеймворк не має значення, тільки швидкість та якість (маштабування, бюджет тощо. )) Пишу на джанго багато років, коли знадобился FastAPI проблем не виникло 3-4 години і проект розгорнут, але ж адмінка і міграції із коробці варті того. Рєзюме — час і грощі — і хоч власний фреймворк )

Відповісти
Підтримати
Anatoliy Kyrinnyy python developer в self employed 27.09.2022 13:03

Для тих, у кого багато грошей на AWS може і так.
Але ще чомусь забувають про обмеження самого serverless.
Це ми вже проходили, коли всі казали що окрім mongodb нічого більше не потрібно :)

Відповісти
Підтримати
Stas K Software Engineer 13.10.2022 13:15
Це ми вже проходили, коли всі казали що окрім mongodb нічого більше не потрібно :)

...і роблять з монги ті ж самі таблиці і зв’язки між ними, по принципам реляційних баз даних.. 😢

Відповісти
Підтримати
Anatoliy Kyrinnyy
Андрій Петрів 12.09.2022 13:14

Django має свою нішу, FastAPI свою.
У нас основа на джанго, мікросервіси — Джанга, Фласк, FastAPI.
Фласк я би вже помалу хоронив. FastAPI краще в усіх відношеннях. Хіба ще бібліотек менше.
Відповідно Джанга має дуууже багато бібліотек на всі випадки життя.
Адмінка, авторизація з коробки, єдина ORM, стандарти розробки. Щоб це все прикрутити на FastAPI треба бюджет х2 а той й х3.
Тому найкраще стартувати з Джанги, потім виділяти FastAPI мікросервіси.
Celery працює з обома.
Ну і best practices — black, pytest, full coverage, type hinting.

Відповісти
Підтримати
Дмитро Python Tech Lead в Amplio 12.09.2022 12:07

Пишу на джанго вже 12 років. Останні 5 пишу на джанго тільки тому, що він вже використовувався. Якщо є можливість не брати джангу — за любки не беру. Надаю перевагу aiohttp/fastapi

Відповісти
Підтримати
Yevhenii Hyzyla Python developer 11.09.2022 14:36

Все менше бачу, щоб починали на Django робити нові проекти і все частіше бачу як беруть FastAPI. Але це не заперечує того факту, що Django популярний фреймворк і багато всього вже написано на ньому і інколи написано не дуже якісно або нашвидкоруч. Якщо вам подобається Django і ви впевнені у своїх силах, то можна спробувати розвивати і продавати себе під гаслом «Наведу лад на вашашому Django проекті: додам типізацію, напишу тести, оптимізую запити, відділю бізнес логіку від роботи з бд, поділю проект по незалежних доменах, та інше». Як на мене, на сталих Django проектах запит, щоб хтось прийшов і поприбирав дуже високий. А вже з гарно написаним і охайним Django проектом працювати не менш комфортно, ніж з FastAPI, де бардак ще не встигли наробити.

Щодо питання «моноліт чи мікросервіси», то я обираю моноліт за замовчуванням і мікросервіси, як еволюційний крок моноліту. Для мікросервісів Django теж ОК варіант — гарно ізольовані Django апки, можуть легко перетворитися в самостійні мікросервіси, тому тут лише питання у власній майстерності

Відповісти
Підтримати
Oleh Smolynets 11.09.2022 15:01

«поділю проект по незалежних доменах» — ви тут маєте на увазі рознести логіку по окремих апклікаціях в межах джанго проекту?

Відповісти
Підтримати
Yevhenii Hyzyla
Yevhenii Hyzyla Python developer 11.09.2022 15:08

Так-так, і особливо так, щоб спілкування між цими апками було мінімальним або лише через API application/bussines рівня — ніяких SQL JOIN моделей з двох апок. Чому так? щоб легше було виносити в якісь мікросервіси і тестувати апки незалежно один від одного.

Відповісти
Підтримати
Oleh Smolynets
Oleh Smolynets 11.09.2022 15:17

Та, шось таке робив на попедніх проектах. Погоджуюсь — це дуже зручно. Правда «щоб спілкування між цими апками було мінімальним або лише через API application/bussines рівня » - незавжди то виходило але тут мені ше вчитися і вчитися)

Відповісти
Підтримати
Yevhenii Hyzyla
Oleh Smolynets 11.09.2022 22:22

«Відділю бізнес логіку від роботи з бд» — тут мається наувазі Fatmodel (бізнес логіка в методах моделей)? Ви важаєте це поганою практикою і не використовуєте в своїх проектах? Якшо так, то де ви тримаєте бізнес логіку?

Відповісти
Підтримати
Yevhenii Hyzyla
Yevhenii Hyzyla Python developer 11.09.2022 23:47

Тут питання спірне і не все треба сприймати як чітке правило, але бачу, що в бекенд розробці склався консенсус, як ділити логіку для типового проєкту:

  • Рівень презентації — view в якому немає ніякої бізнес-логіки, окрім як розпарcити дані та передати їх у сервіс, також серіалізувати відповідь сервісу на вихід. Так зможете для однієї і тієї ж логіки додати різні інтерфейси/представлення: Rest, JSON API, GRPC, HTML або змінити формат відповіді, не змінюючи самої бізнес-логіки.
  • Рівень бізнес-логіки/сервісний рівень/доменний рівень — тут живе ваша бізнес-логіка, валідації і запити в інші сервіси. Треба старатися, щоб цей рівень взагалі не залежав від view — не було роботи з request об’єктом, щоб можна було викликати в якомусь місці, де цього request немає. Для прикладу, щоб можна було викликати метод з бізнес-логікою в Celery задачі і в view моделі одночасно
  • Рівень роботи з базою даних — на цьому рівні живуть невеликі функції для роботи з БД: щось створити у базі, щось видалити, щось оновити. Для Django не дуже поширена практика виділяти цей рівень, але я особисто робив би і його. Які переваги виділяти цей рівень: твій сервісний рівень не вдається до деталей як працювати з базою (легше читати), легше замінити сховище для якоїсь з моделей (для прикладу, якісь гарячі моделі вирішили перемістити в redis)

Гарно про такий підхід описано у Django Styleguide

Якщо говорити в контексті вже зрілих проєктів, то, я особисто бачу, найбільшу перевагу такого підходу це чітке бачення для команди в якому напрямку рухатися для організації коду.

Відповісти
Підтримати
Oleh Smolynets
Bohdan Krupa 11.09.2022 12:21

Майбутнє за serverless, без flask, fastapi та django

Відповісти
Підтримати
Full Stackly 11.09.2022 12:22

Розгорніть будь-ласка. Дуже цікаво почитати, хто розуміє тренди.

Відповісти
Підтримати
Bohdan Krupa
Kyryl SWE 12.09.2022 11:36

Як без flask, fastapi або Django обробити запит у serverless оточені (Cloud Functions наприклад)? Якийсь фреймворк для валідації і всякого такого все одно використовується. Просто без своїх **icorn-воркерів.

Відповісти
Підтримати
Bohdan Krupa
Dmytro Brahinets Delivery lead в Uinno 27.09.2022 13:38

Це так само як казать, майбутнє за Х замість Y — підстав будь яку мову, і ще шось. Але як завжди все залежить від вимог, як функціональних так і нефункціональних. І якщо інколи serverless лягає просто шикарно, то інколи то як п’ята нога.

Відповісти
Підтримати
Bohdan Krupa
Nataliia Kushnir Python Software Developer 11.09.2022 11:43

Додам в резюме рядок "Пишу нові проекти на Django"😊
Коли ти диктуєш стек, а не клієнт, то якось простіше 🙃

Якщо вивчивши Django ви почнете писати швидко і якісно, то ознайомившись з flask ви будете вчитись писати постійно.

Ясно, що після Джанго у фласка все треба ручками робити.

Не знаю, що там по вакансіям, бо давно не дивилась, але для мене, людина, що пише на Джанго однозначно більш кваліфікована.

Робіть те, що подобається, а не те, що диктує ринок. Робіть те, що вмієте добре, а не всього по-трішки і ви точно знайдете свого працедавця.

Відповісти
Підтримати
Bohdan Demydov 11.09.2022 14:33

але для мене, людина, що пише на Джанго однозначно більш кваліфікована.

Хмммм.... Так ніби навпаки, людина яка пише працює з фласк мала бути б більше кваліфікована, так як там більшість речей, які в Джанго йдуть з коробки, треба самому писати.

Відповісти
Підтримати
Nataliia Kushnir
Nataliia Kushnir Python Software Developer 11.09.2022 14:40

Та ні, в Джанго розібрались і написати можете. А у фласка тикаєтесь, поки буде якісно.
Там де написано "для мене"😊

Відповісти
Підтримати
Bohdan Demydov
Євген Tech Lead Manager в Preply 11.09.2022 11:05

Django — це хороший інструмент, багато успішних компаній мають моноліт на його базі (preply, DOU, djinni, instagram тощо). У зв’язку з розвитком фронтенд фреймворків зараз частіше використовується лише для бекенду + адмінка. Якщо розберешся з Джанго, то навчитися користуватися іншим фреймворком займе від дня до тижня.

Як вже сказали, головне освоїти принципи написання бекенду, бекенд-фреймворки між собою досить схожі.

Відповісти
Підтримати
Дмитрий Корбаницкий Python Developer 11.09.2022 14:38

>>Якщо розберешся з Джанго, то навчитися користуватися іншим фреймворком займе від дня до тижня.
Вот тут в точности да наоборот. В Джанго всё настолько далеко спрятано, что зачастую занимаешься не программированием, а конфигурирование. И те, кто начинал с Джанго, очень часто не знают как именно оно работает под капотом. Очень часто на собесах на базовые вопросы по вебу, мне отвечают «ну я точно не знаю как, вот в Джанго надо такой параметр прописать и будет работать». А написав что-то на фласке или Фаст апи, ты понимаешь как устроена обработка реквеста и новые фреймоврки уже осваиваются легче.

Відповісти
Підтримати
Євген
Vlad N 11.09.2022 14:48

+1) Будеш розбиратись в абстракціях джанго)

Відповісти
Підтримати
Дмитрий Корбаницкий
Stas K Software Engineer 11.09.2022 11:04
але він мені не дуже подобається.

чим саме не подобається? давай детальніше

Відповісти
Підтримати
Oleh Smolynets 12.09.2022 16:29

Джанго дає дуже багато вже з коробки, а на фласк то треба все докручувати і головне то правильно скомпонувати. Звідси витікає — джанго вже само по собі будує правильну архітектуру, а на фласк можна дуже по різному все робити, але шоб правильно — треба мати з ним певний досвід. Принаймі таке моє враження від фласка після 3 років роботи тільки з django/drf

Відповісти
Підтримати
Stas K
Dan 12.09.2022 22:27
джанго вже само по собі будує правильну архітектуру,

Хорошо пошутил )

Відповісти
Підтримати
Oleh Smolynets
Artem Olenchenko 13.10.2022 12:58

Для меня проблемы начинаются когда я хочу другую правильную архитектуру прикрутить

Відповісти
Підтримати
Oleh Smolynets
Maksym Mospanenko Software Engineer 11.09.2022 10:59

головне вміти вирішувати проблеми, також варто розуміти для чого джанго, її плюси₴мінуси, особливості архітектури (та її обмеження, — я про Active Record), за цей час поглиблювати знання в архітектурі, інакше скоро набридне штампувати проекти на фреймворках

Моє бачення що роботи менше не стане, а моноліт чи мікросервіси — це взагалі про менеджмент (до чого тут інструмент?)

fastapi виглядає теж привабливо, але не вчить/програмуйте фреймворк, інструмент на реальному (я не про POC) проекті не повинен займати якусь значущу роль

Відповісти
Підтримати

Підписатись на коментарі

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.