django vs flask vs node
Flask и Django са базирани на Python рамки за уеб разработка. Този урок сравнява Django срещу Flask в детайли. Flask срещу Node също е покрит накратко:
Винаги е била повсеместна дилема, когато става въпрос за избора на рамка за следващия ви проект. На всеки няколко месеца виждате нова технология и рамка, която преодолява слабостта на предишната, която сте използвали.
Структурата е по-скоро като мълчалива култура и набор от конвенции, които трябва да следвате, за да бъдете по-подходящи и продуктивни в този постоянно променящ се свят на технологиите. Сравнително, уеб разработката се движи много по-бързо от настолната разработка.
=> Прочетете поредицата за обучение на колби
Какво ще научите:
Джанго срещу Колба
В този урок правим подробно сравнение между Django и Flask. Flask и Django са базирани на Python рамки за уеб разработка. Много от тях преминават към леки микрорамки. Тези рамки са гъвкави, гъвкави, малки и помагат за разработването на микроуслуги и безсървърни приложения.
Предвид популярността на NodeJS, ние също предоставихме сравнение на чудо между Flask и Node в раздела Flask vs Node. Оценяването на Django и Flask по следните характеристики ще ви помогне при избора един върху друг.
Администратор по подразбиране
И двете рамки предоставят заредено администраторско приложение. В Django той е вграден и идва с инсталацията по подразбиране. В случая на Flask обаче трябва да инсталирате Flask-Appbuilder, за да имате администраторски интерфейс.
Междувременно, не забравяйте да създадете суперпотребител в Django и администратор в случай на Flask, за да можете да влезете в административната бекенда с помощта на браузъра.
Бази данни и ORMS
Django се доставя с вграден ORM по подразбиране, който директно поддържа взаимодействие с RDBMS като Oracle, MySQL, PostgreSQL, SQLite и др. Този ORM също така поддържа генерирането и управлението на миграции. Относително по-удобно е да създавате модели на бази данни с вградени валидации.
Flask също не налага някакъв конкретен метод и е на разположение за използване с различни разширения, които поддържат подобни функции, както е описано в случая с Django. Дадохме примери за Flask-SQLAlchemy, Flask-Migrate, Flask-MongoEngine, в един от уроците от поредицата.
Изгледи и маршрути
И двете рамки имат механизми за деклариране на възгледи, базирани на методи и на класа. В случая с Django маршрутите и изгледите се споменават в отделни файлове. Също така, винаги трябва да предаваме обекта на заявката изрично.
От друга страна, в Flask можем да използваме декоратор, за да споменем маршрутите за съответните манипулатори. Обектът за заявка в Flask е глобален и е просто достъпен без изрично преминаване. Ние разгледахме подробно концепциите за използване на изгледи и маршрути в един от нашите уроци.
Форми и шаблони
Django формулярите са вградени в рамката и не изискват инсталация. Формулярите са доста важни за приложенията, а в Django формулярите могат да се предават на маркери на шаблони и са достъпни за изобразяване в шаблони. В случая с Flask обаче трябва да използваме Flask-WTF.
Също така използвахме Flask-Appbuilder за създаване на формуляри. Освен това WTF-Alembic може да се използва за генериране на HTML форми, базирани на модели на бази данни.
И двете рамки поддържат Jinja2 шаблониране, и двете поддържат обслужването на статични файлове с вградени функции за генериране на URL адресите на ресурсите и е доста често срещан модел във всички рамки в наши дни.
Въпреки че има различни начини за предаване на променливите и за изобразяване на шаблоните в техните конкретни методи на изглед, и двете рамки имат един и същ синтаксис за достъп до променливи в шаблони.
Гъвкавост
Django, поради огромния си размер и сложност, е по-малко гъвкав от Flask. Колбата може лесно да бъде разширена с помощта на голям брой разширения, които тя поддържа. Следователно е необходимо повече време и усилия за настройване на Flask, защото трябва да оценим повече разширения.
Свободата, предоставена на разработчиците по някакъв начин, води до по-бавно разработване и доставка. От друга страна, Django следва набор от вече установени конвенции и следва архетипите, които изискват по-малко отклонение от целите и задачите на проекта.
Крива на обучение
Почти изисква същото количество време, за да научите и Django, и Flask. Flask има по-малък API; следователно хората могат да успеят да го завършат по-бързо, що се отнася до основната рамка. Става също толкова предизвикателно, когато става въпрос за използването на неговите разширения. Скоро може да стане тромаво.
Въпреки това, само защото всичко не е опаковано в един пакет, е по-лесно да се практикува разделяне на проблемите в случая с рамката на Flask.
Препоръчваме ви да научите моделите, а не синтаксиса, който се следва. И Django, и Flask имат отлична документация. Можете лесно да го следвате, докато разработвате функция.
Размер и продължителност на проекта
Когато работите по по-голям проект с по-големи екипи, по-добре е да се възползвате от зрелостта на Django и от обширната подкрепа на сътрудниците, която има. Ако вашият проект е по-малък и изисква по-малък брой разработчици, по-добре е да използвате Flask.
Освен това, ако вашият проект ще продължи дълго, тогава Django е правилният избор; в противен случай можете да изберете Колба.
Тип на приложението
По-рано Django се смяташе за правилният избор, когато имаше изискване за пълноценни уеб приложения на корпоративен мащаб. Но днес Flask е еднакво зрял и може да служи добре при същите условия.
Въпреки това, разработчиците са склонни да избират Flask повече за разработване на малки или статични уебсайтове или докато внедряват бързи за предоставяне на RESTful API уеб услуги.
Набиране на разработчици
Наличието на квалифицирани ресурси в съгласуването на рамката, която използвате, се отплаща. Можете да очаквате по-бързо развитие, по-бързо тестване, по-бърза доставка и по-бързи корекции на проблеми.
Доста е лесно да се намерят нови разработчици в случая на Flask. Предизвикателство обаче е да се намерят квалифицирани ресурси в Django. Не са много готовите да бъдат наети от разработчиците на Django. Освен това рамката на Django е доста стара и следователно повечето от новите наеми са скъпи за наемане в сравнение с тези, които са квалифицирани в рамката на Flask.
Новите технически възпитаници също взимат леки рамки като Flask, защото индустриалните тенденции са насочени към създаване на приложения с отделени микроуслуги или технология, която подкрепя създаването на безсървърно изпълнение. Javascript се използва широко заедно с рамките, които са по-лесни за използване и са по-популярни.
Отворен код
Както Flask, така и Django са проекти с отворен код. Можете да намерите Django на https://github.com/django/django и Flask на https://github.com/pallets/flask. Разглеждайки тези проекти, броят на сътрудниците на Django е доста по-голям от тези, допринасящи за Flask.
Следователно можем да очакваме повече и по-бърза поддръжка, ако имаме някои проблеми и заявки, които се нуждаят от разрешаване. Противно на типичните предположения, броят на потребителите на проекта Flask е по-висок от този на Django.
Един загрижен факт за Flask е, че може да няма стабилно разширение за определена задача. Следователно работата по филтрирането на най-доброто остава за потребителя на разширението.
Например, използвахме Flask-Twitter-oembedder за работа с API на Twitter в последния урок, но това разширение имаше някои проблеми, поради които трябваше да преминем от Flask-Cache към Flask-Caching.
Дори трябваше да включим заявка за персонализирана инсталация, за да инсталираме Flask-twitter-oembedder от нашето актуализирано репо Github, вместо да го споменаваме в нашия файл requrements.txt на проекта.
Честата поддръжка е типично предизвикателство, с което ще се сблъскате с проект с отворен код. Подкрепата и управлението на проекта с отворен код обикновено са обвързани с платени услуги. Може да се наложи да чакате дълго време, за да отстраните няколко проблема от участниците в проекта.
производителност
Рамката на Flask е по-лека от Django и се представя по-добре с незначителни разлики, особено докато се обмислят I / O операции.
Погледнете сравненията, дадени по-долу. С увеличаването на заявките производителността на Flask остава почти същата. Django обаче отнема повече време за изобразяване на шаблони след извличане на данни с помощта на ORM.
Python Flask срещу Django: Таблично сравнение
| # | Характеристика | Джанго | Колба |
|---|---|---|---|
| 7 | Променлива интерполация в шаблони | В templates / demo.html {{tempvar}} | В templates / demo.html {{tempvar}} |
| 1 | Администратор по подразбиране | Вграден администратор Backend | Инсталирайте Flask-Appbuilder |
| две | Активирайте администратора по подразбиране | В settings.py се уверете, че коментирате инсталираното от администратора приложение. ... # Определение на приложението INSTALLED_APPS = ( 'уебсайт', 'django.contrib.admin', # друг код ) ... | Импортирайте AppBuilder и SQLA от flask_appbuilder, първо инициализирайте DB и след това Appbuilder от колба за внос Колба от flask_appbuilder импортиране на AppBuilder, SQLA ап = колба (__ име__) db = SQLA (приложение) appbuilder = AppBuilder (приложение, db.session) |
| 3 | Създайте администраторски потребител | python manage.py създаваuperuser | flask fab create-admin |
| 4 | Бази данни и ORMS | Вграден ORM за RDBMS Използвайте Django-nonrel за NoSQL backends | Инсталирайте Flask-SQLAlchemy Специално разширение на флакон NoSQL като Flask-MongoEngine |
| 5 | Изгледи и маршрути | URLConf в urls.py от пътя за импортиране на django.urls от .import изгледи urlpatterns = ( path (’/ path’, views.handler_method), # други URL адреси и манипулатори ) | Използвайте декоратор @ app.route (“/ path”) в Views, за да картографирате маршрут с функция. @ app.route („/ път“) def handler_method (): # друг код с допълнителна логика |
| 6 | Шаблони за визуализиране | В гледки от django.shortcuts импортиране на визуализация def example_view (заявка): tempvar = 'стойност_за_шаблон' връщане на визуализация ( искане, ‘Demo.html’, {'Tempvar': tempvar} ) | В гледки от. приложение за импортиране от заявка за импорт на колба от импортиране на колба render_template @ app.route („/ път“) def demo (): tempvar = 'стойност_за_шаблон' връщане render_template ( “Demo.html”, temp_var = temp_var ) |
| 8 | Гъвкавост | По-малко гъвкави | По-гъвкави |
| 9 | Решения за проектиране | По-малко дизайнерски решения с разработчици. | Повече свобода за разработчиците. |
| 10 | Проектно отклонение | По-малко отклонение от целите на проекта. | Повече отклонения поради свободата, предоставена на разработчиците. |
| единадесет | Размер на Codebase | По-голяма кодова база | По-малка кодова база |
| 12 | Брой API | Още API | По-малко API |
| 13 | Тип на приложението | Пълни уеб приложения | По-малки приложения / микроуслуги |
| 14. | RESTful приложения | Django REST рамка за RESTful приложения. | Използвайте следните разширения за RESTful приложения. Колба-RESTful Колба-RESTX Влизам |
| петнадесет | производителност | Бавно изпълнение, когато броят на заявките е голям. | Постоянно представяне през цялото време. |
| 16. | Приноси с отворен код | Повече брой вилици, часовници и ангажименти. | По-малък брой вилици, часовници и ангажименти. |
| 17 | Разработчици | Изисква опитни разработчици и не са лесно достъпни за набиране. | Повечето от разработчиците са по-малко опитни и се намират в адекватен брой. |
Колба срещу възел
По отношение на стека за уеб разработка се оказва, че разработването за мрежата изисква обединяване на различни технологии. Трябва да разделим уеб приложението на интерфейс и бекенд. Предната част на приложението е най-добре разработена от технологиите, които се изпълняват в браузъра, като JavaScript, HTML и CSS.
Като цяло, бекендът е разработен на езици, които са подходящи за сървъра и могат да взаимодействат с основната операционна система, свързани бази данни или мрежата, когато е необходимо.
Въпреки това, базирана на JavaScript рамка, наречена NodeJS, промени горния изглед и позволи на разработчиците да имат последователност и еднаквост в предния и задния край на разработката за уеб приложения. Разработчиците биха могли да разработят за заден край с помощта на JavaScript.
В тази секция Flask срещу Node сравняваме Flask, която е рамка, базирана на езика за програмиране на Python, с Node, която се основава на изпълнението на JavaScript на Chrome по различни критерии като архитектура, скорост, поддръжка на общността и т.н.
| # | Критерии | Колба | Възел |
|---|---|---|---|
| 7 | Отстраняване на грешки | По-лесно е да отстранявате грешки с Python дебъгер без зависимости. | Изисква повече усилия. По-лесно с IDE за разработка с библиотека Bluebird / Promise. |
| 1 | Изпълнение на езика | Python | JavaScript Engine V8 на Chrome |
| две | Архитектура | Неблокиращият вход / изход изисква използването на неблокиращи уеб сървъри като gunicorn. Категория микрорамки (отзад). | По своята същност осигурява неблокиращи I / O. Категория Fullstack |
| 3 | Мениджър на пакети | пип | над морското равнище |
| 4 | Скорост | По-бавно поради отделен интерпретатор на Python. | По-бързо заради компилатора Just-In-Time. |
| 5 | Отворен код | Да | Да |
| 6 | Подкрепа от общността | На Github 2.3 K часовници 51.4 K звезди 13,7 K вилици | На Github 2.9 K Часовници 71,9 K звезди 17,6 K Вилици |
| 8 | Поддръжка | Ниска поддръжка | По-висока поддръжка |
| 9 | Приложения в реално време | По своята същност не е подходящ. Въпреки това, той може да работи заедно със socket.io за случаи в реално време. Използвайте разширението Flask-socketio. | Подходящ поради управлявана от събития архитектура и поточни модули. По своята същност асинхронни. |
| 10 | Библиотеки | По-зрял и стабилен. | По-малко зрели и стабилни, но в рамките на активното разработване и поправки. |
| единадесет | Качество на кода | Той е създаден изключително за задния край. | Понякога е компрометиран, тъй като новите разработчици на предни устройства преминават към бекенда. |
| 12 | Състав на екипа за разработчици | Екипите обикновено се състоят от разработчици от задния край и разработчици от предния край. Притесненията са отделни. | Разработчиците могат да обменят роли и да работят както за предния, така и за задния край. |
| 13 | Интеграция със съществуваща система и приложения | По-лесно се интегрира с други съществуващи стари приложения, използвайки екосистемата на Python за машинно обучение и приложения за големи данни. | Доста ново и изисква създаването на персонализирани или нови библиотеки за интеграция с други съществуващи приложения. |
често задавани въпроси
В # 1) Какво трябва да науча първо, Django или Flask?
Отговор: По-добре е първо да отидете с Flask. След като натрупате малко опит в уеб разработката, можете да се заемете с Django. Django предполага, че вече знаете как работят уеб приложенията и той се грижи за по-голямата част от функционалността сам.
В # 2) Flask или Django по-добри ли са?
Отговор: Както Flask, така и Django са отлични и отговарят на целта си. Django се използва за създаване на по-известни корпоративни приложения. Колбата се използва за създаване на статични и по-малки приложения. Колбата е подходяща и за прототипиране. С използването на разширенията на Flask обаче можем да създадем и големи приложения.
В # 3) Кои компании използват Flask?
как се отварят jar файлове
Отговор: Някои от компаниите, които използват Flask, са Reddit, Mailgun, Netflix, Airbnb и др.
В # 4) Какви сайтове използват Django?
Отговор: Някои от сайтовете, които използват Django, са Instagram, Spotify, YouTube, Dropbox, Bitbucket, Eventbrite и др.
Заключение
Не бива да се фиксираме за дълго с една рамка. Трябва да сме готови да научим нови набори от технологии и да възприемем тенденциите там. Някои от нас искат сравнително нестандартно, батерията включва подходи с твърди цикли на освобождаване, поддържащи по-строга обратна съвместимост и т.н.
Ако смятате, че принадлежите повече към тази група, тогава трябва да изберете Django. Невероятно е обаче да се разхождате заедно с нови функции и гъвкавост на рамката на Flask. Когато искате да поддържате съгласуваност между предния край и бекенда, можете да изберете рамка с пълен стек, като NodeJS.
Преминаването с рамка е по-скоро избор, който зависи от контекста и проблемите, които се опитваме да решим. Изборът на рамка винаги е труден. Надяваме се, че сме представили основните точки за преглед в този урок и това ще ви помогне при финализирането на една рамка. Препоръчваме обаче да изучите и двете рамки.
По-лесно е да започнете с Flask и след това да преминете към Django, след като сте натрупали известен опит в уеб разработката. Ако по някаква причина усилията ви за разработка изискват използването на JavaScript, тогава можете да продължите с NodeJS.
=> Проверете ВСИЧКИ уроци за колби тук
Препоръчително четене
- Урок за Python Django - Първи стъпки с Django
- Модели за дизайн на колби и най-добри практики за уеб приложения
- Шаблон на колба, формуляр, изглед и пренасочване с примери
- Топ 31 популярни въпроса за интервю с Python Flask с отговори
- Как да настроите рамката за тестване на Node.js: Урок за Node.js
- Урок за TestNG: Въведение в TestNG Framework
- Управлявана от ключови думи рамка в селен с примери
- Урок за Robot Framework - функции и инсталиране на софтуер