django vs flask vs node
Flask i Django són marcs de desenvolupament web basats en Python. Aquest tutorial compara en detall Django vs Flask. Flask vs Node també es tracta breument:
Sempre ha estat un dilema imperatiu quan es tracta de seleccionar un marc per al vostre proper projecte. Cada pocs mesos, veieu una nova tecnologia i un marc que supera la debilitat de l’anterior que utilitzaveu.
Un marc s’assembla més a una cultura silenciosa i a un conjunt de convencions que heu de seguir per ser més rellevants i productius en aquest món tecnològic en constant canvi. Comparativament, el desenvolupament web es mou molt més ràpid que el desenvolupament d'escriptori.
=> Llegiu tota la sèrie d'entrenament de Flask
Què aprendreu:
Django Vs Flask
En aquest tutorial, traiem una comparació detallada entre Django i Flask. Flask i Django són marcs de desenvolupament web basats en Python. Molts s’estan avançant cap a microframes lleugers. Aquests marcs són àgils, flexibles, petits i ajuden a desenvolupar microserveis i aplicacions sense servidor.
Tenint en compte la popularitat de NodeJS, també hem proporcionat una comparació de prodigi entre Flask i Node a la secció Flask vs. Node. Avaluar Django i Flask amb les funcions següents us ajudarà a seleccionar-ne una sobre l’altra.
Administrador predeterminat
Tots dos marcs proporcionen una aplicació d'administrador arrencada. A Django, està integrat i inclou la instal·lació per defecte. Tot i això, en el cas de Flask, heu d’instal·lar Flask-Appbuilder per tenir una interfície d’administració.
Mentrestant, recordeu de crear un superusuari a Django i administrador en el cas de Flask perquè pugueu iniciar sessió al backend d'administració mitjançant el navegador.
Bases de dades i ORMS
Django s'envia amb un ORM predeterminat integrat que admet de forma directa la interacció amb RDBMS com Oracle, MySQL, PostgreSQL, SQLite, etc. Aquest ORM també admet la generació i gestió de migracions. És relativament més còmode crear models de bases de dades amb validacions incorporades.
Flask tampoc no imposa cap mètode concret i està disponible per utilitzar-se amb diverses extensions que admetin funcions similars tal com es descriu en el cas de Django. Hem donat exemples de Flask-SQLAlchemy, Flask-Migrate, Flask-MongoEngine, en un dels tutorials de la sèrie.
Vistes i rutes
Tots dos marcs tenen mecanismes per declarar vistes basades en mètodes i basades en classes. En el cas de Django, les rutes i les vistes s’esmenten en fitxers separats. A més, sempre hem de passar explícitament l’objecte de sol·licitud.
D'altra banda, a Flask, podem utilitzar un decorador per esmentar les rutes dels manipuladors corresponents. L'objecte de sol·licitud a Flask és global i només està disponible sense passar explícitament. Hem detallat els conceptes d’utilitzar vistes i rutes en un dels nostres tutorials.
Formularis i plantilles
Els formularis Django s’incorporen al framework i no requereixen cap instal·lació. Els formularis són força essencials per a les aplicacions i, a Django, els formularis es poden passar a les etiquetes de plantilla i estan disponibles per representar-les a les plantilles. Tot i això, en el cas de Flask, hem d’utilitzar Flask-WTF.
També vam fer servir Flask-Appbuilder per crear formularis. A més, WTF-Alembic es pot utilitzar per generar formularis HTML basats en models de base de dades.
Tant els frameworks admeten la plantilla Jinja2, com ambdós admeten la publicació de fitxers estàtics amb funcions incorporades per generar les URL dels recursos i és un patró força comú en tots els frameworks actualment.
Tot i que hi ha diferents maneres de passar les variables i de representar les plantilles en els seus mètodes de visualització particulars, els dos marcs tenen la mateixa sintaxi d'accés a les variables de les plantilles.
Flexibilitat
Django, per la seva gran mida i complexitat, és menys flexible que Flask. Flask es pot ampliar fàcilment amb l'ajut d'un gran nombre d'extensions que admet. Per tant, necessita més temps i esforç per configurar Flask perquè hem d’avaluar més extensions.
La llibertat que es dóna als desenvolupadors en certa manera resulta en un desenvolupament i entrega més lents. D’altra banda, Django segueix un conjunt de convencions ja establertes i segueix els arquetips que requereixen menys desviació dels objectius i objectius del projecte.
Corba d'aprenentatge
Gairebé requereix la mateixa quantitat de temps per aprendre tant Django com Flask. Flask té una API més petita; per tant, és possible que la gent pugui acabar-lo més ràpidament pel que fa al marc bàsic. Es fa igual de difícil quan es tracta d’utilitzar les seves extensions. Pot ser avorrit aviat.
No obstant això, pel fet que tot no està empaquetat en un paquet, és més fàcil practicar la separació de preocupacions en el cas del framework Flask.
Us recomanem que apreneu els patrons i no la sintaxi que se segueix. Tant Django com Flask tenen una documentació excel·lent. Podeu seguir-lo fàcilment mentre desenvolupeu una funció.
Mida i durada del projecte
Quan treballeu en un projecte més gran amb equips més grans, és millor aprofitar-vos de la maduresa de Django i del gran suport per als col·laboradors que té. Si el vostre projecte és més petit i requereix un nombre menor de desenvolupadors, és millor anar amb Flask.
A més, si el vostre projecte durarà molt de temps, llavors Django és l'elecció correcta; en cas contrari, podeu seleccionar Flask.
Tipus d'aplicació
Abans es considerava que Django era l’elecció correcta quan hi havia un requisit per a aplicacions web a tota escala a escala empresarial. Però, avui en dia Flask és igual de madur i pot servir bé per a les mateixes condicions.
Tanmateix, els desenvolupadors tendeixen a triar Flask més per desenvolupar llocs web petits o estàtics, o mentre implementen serveis web de RESTful API de forma ràpida.
Contractació de desenvolupadors
Tenir recursos especialitzats en la convenció del marc que utilitzeu compensa. Podeu esperar un desenvolupament més ràpid, proves més ràpides, lliurament més ràpid i solucions de problemes més ràpides.
És bastant fàcil trobar nous desenvolupadors en el cas de Flask. Tot i això, és difícil trobar recursos especialitzats a Django. No hi ha molts preparats per ser contractats pels desenvolupadors de Django. A més, el marc de Django és bastant antic i, per tant, la majoria de les noves contractacions són costoses de contractar en comparació amb les persones expertes en el marc de Flask.
Els nous graduats tècnics també recullen marcs lleugers com Flask, perquè les tendències de la indústria es dirigeixen cap a la creació d'aplicacions amb microserveis desacoblats o la tecnologia que admet la creació de la implementació sense servidor. Javascript s’utilitza àmpliament juntament amb els marcs més fàcils d’utilitzar i que són més populars.
Codi obert
Tant Flask com Django són projectes de codi obert. Podeu trobar Django a https://github.com/django/django i Flask a https://github.com/pallets/flask. Veient aquests projectes, el nombre de col·laboradors de Django és bastant més extens que els que contribueixen a Flask.
Per tant, podem esperar més assistència i més rapidesa si tenim problemes i consultes que necessiten resolució. Contràriament a les suposicions típiques, el nombre d’usuaris del projecte Flask és superior al de Django.
Un fet rellevant sobre Flask és que podria no haver-hi una extensió estable per a una tasca en particular. Per tant, el treball de filtrar el millor queda a l’usuari de l’extensió.
Per exemple, vam utilitzar Flask-Twitter-oembedder per treballar amb l’API de Twitter a l’últim tutorial, però aquesta extensió va tenir alguns problemes a causa dels quals vam haver de canviar de Flask-Cache a Flask-Caching.
Fins i tot vam haver d’incloure una declaració d’instal·lació personalitzada per instal·lar Flask-twitter-oembedder des del repositori Github actualitzat en lloc d’esmentar-lo al nostre fitxer requrements.txt del projecte.
El manteniment freqüent és un repte típic que afrontareu amb un projecte de codi obert. El suport i la gestió del projecte de codi obert solen estar lligats a serveis de pagament. És possible que hagueu d’esperar molt de temps per solucionar alguns problemes dels col·laboradors del projecte.
Rendiment
El marc Flask és més lleuger que Django i té un rendiment millor amb diferències insignificants, sobretot si es tenen en compte les operacions d'E / S.
Vegeu les comparacions que es donen a continuació. Amb l’augment de sol·licituds, el rendiment de Flask es manté pràcticament el mateix. Tot i això, Django triga més temps a representar plantilles després d’obtenir dades mitjançant l’ORM.
Python Flask Vs Django: una comparació tabular
# | Característiques | Django | Flascó |
---|---|---|---|
7 | Interpolació variable en plantilles | A templates / demo.html {{tempvar}} | A templates / demo.html {{tempvar}} |
1 | Administrador predeterminat | Fons d’administració incorporat | Instal·leu Flask-Appbuilder |
2 | Activa l'administrador predeterminat | A settings.py, assegureu-vos que descomenteu l'aplicació instal·lada per l'administrador. ... # Definició de l'aplicació INSTALLED_APPS = ( 'lloc web', 'django.contrib.admin', # altre codi ) ... | Importeu AppBuilder i SQLA des de flask_appbuilder, inicialitzeu primer la base de dades i després Appbuilder d'importació de matràs Matràs des de flask_appbuilder importeu AppBuilder, SQLA app = Flascó (__ nom__) db = SQLA (app) appbuilder = AppBuilder (aplicació, db.session) |
3 | Crea un usuari d'administrador | python manage.py crea superusuari | flask fab create-admin |
4 | Bases de dades i ORMS | ORM incorporat per a RDBMS Utilitzeu Django-nonrel per als backends de NoSQL | Instal·leu Flask-SQLAlchemy Una extensió de Flask específica de NoSQL com Flask-MongoEngine |
5 | Vistes i rutes | URLConf a urls.py des de la ruta d'importació de django.urls des de vistes .import urlpatterns = ( path ('/ path', views.handler_method), # altres URL i gestors ) | Utilitzeu el decorador @ app.route ('/ path') a Views per assignar una ruta amb una funció. @ app.route ('/ path') def handler_method (): # altre codi amb una lògica addicional |
6 | Representar plantilles | En vistes des de django.shortcuts importar render def example_view (sol·licitud): tempvar = ”value_for_template” tornar render ( sol·licitud, 'Demo.html', {'Tempvar': tempvar} ) | En vistes des de. importació d'aplicacions des de la sol·licitud d’importació de matràs des de la importació de matràs render_template @ app.route ('/ path') demo def (): tempvar = ”value_for_template” retorna el model de render ( 'Demo.html', temp_var = temp_var ) |
8 | Flexibilitat | Menys flexible | Més flexible |
9 | Decisions de disseny | Menys decisions de disseny amb desenvolupadors. | Més llibertat per als desenvolupadors. |
10 | Desviació del projecte | Menor desviació dels objectius del projecte. | Més desviació a causa de la llibertat donada als desenvolupadors. |
11 | Mida de la base de codis | Base de codis més gran | Base de codis més petita |
12 | No d’APIs | Més API | Menys API |
13 | Tipus d'aplicació | Aplicacions web completes | Aplicacions més petites / microserveis |
14 | Aplicacions RESTful | Marc REST de Django per a aplicacions RESTful. | Utilitzeu les extensions següents per a aplicacions RESTful. Flask-RESTful Flask-RESTX iniciar Sessió |
15 | Rendiment | Rendiment lent quan el nombre de sol·licituds és gran. | Rendiment constant a tot arreu. |
16 | Contribucions de codi obert | Més nombre de Forquilles, rellotges i compromisos. | Menor nombre de Forquilles, rellotges i compromisos. |
17 | Desenvolupadors | Requereix desenvolupadors experimentats i no estan fàcilment disponibles per contractar-los. | La majoria dels desenvolupadors tenen menys experiència i es troben en un nombre adequat. |
Flask Vs Node
Respecte a la pila de desenvolupament web, resulta que el desenvolupament per a la web requereix una fusió de diverses tecnologies. Hem de dividir una aplicació web en frontend i backend. La part frontal de l’aplicació es desenvolupa millor en les tecnologies que s’executen al navegador, com ara JavaScript, HTML i CSS.
En general, el dorsal es desenvolupa en idiomes adequats per al servidor i que poden interactuar amb el sistema operatiu subjacent, les bases de dades connectades o la xarxa quan sigui necessari.
Tanmateix, un marc basat en JavaScript anomenat NodeJS va canviar la visualització anterior i va permetre als desenvolupadors tenir consistència i uniformitat en el desenvolupament frontal i posterior de les aplicacions web. Els desenvolupadors podrien desenvolupar-se per a la part posterior mitjançant JavaScript.
En aquesta secció Flask vs Node, comparem Flask, que és un marc basat en llenguatge de programació Python, amb Node, que es basa en el temps d’execució de JavaScript de Chrome en diversos criteris, com ara arquitectura, velocitat, assistència a la comunitat, etc.
# | Criteris | Flascó | Node |
---|---|---|---|
7 | Depuració | Més fàcil de depurar amb el depurador Python sense dependències. | Requereix més esforç. Més fàcil amb un IDE de desenvolupament amb Bluebird / Promise Library. |
1 | Temps d'execució de l'idioma | Python | Motor JavaScript de V8 de Chrome |
2 | Arquitectura | Les E / S sense bloqueig requereixen l’ús de servidors web que no bloquegin com el gunicorn. Categoria Microframework (back-end). | Proporciona inherentment E / S sense bloqueig. Categoria Fullstack |
3 | Gestor de paquets | pip | sobre el nivell del mar |
4 | Velocitat | Més lent a causa d'un intèrpret de Python separat. | Més ràpid gràcies al compilador Just-In-Time. |
5 | Codi obert | Sí | Sí |
6 | Suport a la comunitat | A Github 2.3 K Rellotges 51,4 K Estrelles 13,7 K Forquilles | A Github 2,9 K Rellotges 71,9 K estrelles 17,6 K Forquilles |
8 | Manteniment | Baix manteniment | Manteniment superior |
9 | Aplicacions en temps real | Per si mateix no és adequat. Tot i això, pot funcionar juntament amb socket.io per a casos d’ús en temps real. Utilitzeu l'extensió Flask-socketio. | Adequat a causa de l'arquitectura basada en esdeveniments i els mòduls de transmissió. Intrínsecament asíncrona. |
10 | Biblioteques | Més madur i estable. | Menys madures i estables, però amb un desenvolupament actiu i correcció de versions. |
11 | Qualitat del codi | Està creat exclusivament per a la part posterior. | De vegades es veu compromès a causa dels nous desenvolupadors frontals que canvien al backend. |
12 | Composició de l’equip de desenvolupadors | Els equips solen estar formats per desenvolupadors de back-end i desenvolupadors de front-end. Les preocupacions són independents. | Els desenvolupadors poden intercanviar funcions i treballar tant pel front end com pel back end. |
13 | Integració amb el sistema i les aplicacions existents | Més fàcil d’integrar amb altres aplicacions de backend heretades existents mitjançant l’ecosistema de Python per a l’aprenentatge automàtic i les aplicacions de Big Data. | Bastant nou i requereix la creació de biblioteques personalitzades o noves per integrar-les amb altres aplicacions existents. |
Preguntes freqüents
P # 1) Què he d'aprendre primer, Django o Flask?
Resposta: És millor anar primer amb Flask. Un cop tingueu una mica d’experiència en desenvolupament web, podreu adquirir Django. Django assumeix que ja sabeu com funcionen les aplicacions web i que s’encarrega de la majoria de les funcionalitats per si mateix.
Q # 2) Flask o Django són millors?
Resposta: Tant Flask com Django són excel·lents i adequats per al seu propòsit. Django s’utilitza per crear aplicacions a escala empresarial més destacades. Flask s'utilitza per crear aplicacions estàtiques i més petites. Flask també és adequat per fer prototips. No obstant això, amb l'ús d'extensions de Flask, també podem crear aplicacions grans.
P # 3) Quines empreses utilitzen Flask?
quina és la meva clau de seguretat de xarxa per al punt d'accés de Verizon
Resposta: Algunes de les empreses que utilitzen Flask són Reddit, Mailgun, Netflix, Airbnb, etc.
Q # 4) Quins llocs utilitzen Django?
Resposta: Alguns dels llocs que utilitzen Django són Instagram, Spotify, YouTube, Dropbox, Bitbucket, Eventbrite, etc.
Conclusió
Realment no ens hauríem de fixar amb un marc per molt de temps. Hauríem d’estar preparats per aprendre nous conjunts de tecnologia i adoptar les tendències disponibles. Alguns de nosaltres volem comparativament sortir de la caixa, amb enfocaments inclosos amb bateria amb cicles d’alliberament rígids, mantenint una compatibilitat posterior més estreta, etc.
Si creieu que pertanyeu més a aquest grup, heu de triar Django. Tot i això, és increïble anar junt amb les noves funcions i la flexibilitat del marc Flask. Quan vulgueu mantenir la coherència entre el front end i el backend, podeu triar un framework de pila completa com NodeJS.
Anar amb un marc és més que una opció que depèn del context i dels problemes que intentem resoldre. La selecció d’un marc és sempre difícil. Esperem haver presentat els punts de revisió essencials en aquest tutorial i us ajudarà a finalitzar un marc. Tot i això, es recomana aprendre els dos marcs.
És més fàcil començar amb Flask i després passar a Django després d’haver adquirit una mica d’experiència en desenvolupament web. Si per algun motiu els vostres esforços de desenvolupament requereixen l’ús de JavaScript, podeu continuar amb NodeJS.
=> Consulteu aquí TOTS els tutorials de Flask
Lectura recomanada
- Tutorial Python Django: Introducció a Django
- Patrons de disseny de flascons i bones pràctiques per a aplicacions web
- Plantilla de flascó, formulari, visualització i redirecció amb exemples
- Top 31 de les preguntes més populars de l'entrevista de Python Flask amb respostes
- Com es configura el marc de proves Node.js: tutorial de Node.js
- Tutorial TestNG: Introducció a TestNG Framework
- Marc basat en paraules clau en seleni amb exemples
- Tutorial de Robot Framework: funcions i instal·lació de programari