Quando si inizia a sviluppare un’applicazione web è fondamentale, oltre ad analizzare i requisiti funzionali, scegliere il linguaggio di programmazione e il framework. Per quanto riguarda i linguaggi di programmazione la scelta è vasta e può essere influenzata da diversi fattori. Di sicuro le competenze degli sviluppatori possono far pendere l’ago della bilancia verso una scelta rispetto ad un’altra. Altri fattori potrebbero essere richieste particolari del committente, caratteristiche dell’ambiente in cui l’applicativo dovrà operare o l’uso di software preesistente.
Se siete sviluppatori Python, o amanti di questo linguaggio, la scelta non sarà così difficile, a meno dei vincoli detti in precedenza. A questo punto, il dubbio amletico è: quale web framework Python scegliere? Come al solito in ingegneria la risposta è: dipende! Negli anni, infatti, sono nati molti web frameworks. Alcuni di essi sono diventati popolari, altri sono rimasti di nicchia, mentre altri ancora sono stati abbandonati dopo poco.
Se leggiamo il sondaggio degli sviluppatori Python del 2020 di JetBrains, Django e Flask sono di gran lunga i due web framework Python più popolari. Il loro successo è in parte dovuto alla presenza di comunità mature e all’ampio supporto e popolarità. Inoltre, il loro obiettivo è di fornire l’impalcatura di base dell’applicazione , lasciando al programmatore lo sviluppo delle funzionalità particolari del software. La differenza tra i due framework è come questo obiettivo viene raggiunto.
In questo articolo, esamineremo le caratteristiche e le differenze principali di Django e Flask per individuare il framework più adatto alle esigenze di un’applicazione web.
Filosofia
Django e Flask sono entrambi framework web gratuiti, open-source, basati su Python.
Django è nato nell’autunno del 2003 dall’idea di Adrian Holovaty e Simon Willison. L’obiettivo era, e lo è ancora oggi, di semplificare il processo di sviluppo di siti web. Pertanto la sua filosofia si basa sul modello Model-Template-View (MTV), una variante del modello Model-View-Controller. Lo sviluppo risulta pertanto rapido, con la possibilità di riutilizzare diversi componenti già presenti nel framework. Il partizionamento nei 3 componenti (Model-Template-View) permette inoltre di suddividere il lavoro tra i vari membri di un team di sviluppo oltre ad ottenere un codice pulito e ben strutturato. Lo sviluppo di Django è continuo e all’incirca ogni 6 mesi viene rilasciata una nuova versione. Nonostante ciò, la compatibilità con le versioni precedenti viene mantenuta per quanto sia possibile.
A differenza di Django, Flask è un microframework. Nato come pesce d’aprile da parte di Armin Ronache, ha ottenuto un successo inaspettato. Si basa principalmente su due soluzioni, Werkzeug (un framework per server) e Jinja2 (una libreria di template), già sviluppate da Armin Ronacher. La sua prima versione era un file zip, chiamato Denied Framework, che veniva automaticamente decompresso dal programma di installazione, il quale le eseguiva le due librerie allo stesso tempo. L’architettura di Flask fornisce out-of-the-box il routing delle URL, la gestione delle richieste e degli errori, il templating, i cookie, il supporto per gli unit test, un debugger e un server di sviluppo. Rispetto a Django non fornisce però alcune funzionalità tipiche delle applicazioni web, tra cui un ORM e la gestione dell’autenticazione e dei permessi. Viene lasciata al programmatore la scelta di come personalizzare l’applicazione mediante codice ad-hoc o librerie di terze parti.
Principali differenze tra Django e Flask
Analizziamo le principali differenze tra Django e Flask, per comprendere meglio quale framework è più adatto allo sviluppo di un progetto.
La prima grande differenza tra i due framework è la gestione dei modelli dei dati. Django fornisce un proprio ORM Django (Object-Relational Mapping), mentre Flask no. I modelli dei dati, specialmente quando si lavora con database relazionali, permettono agli sviluppatori di collegare le tabelle del database con le classi del linguaggio di programmazione. In questo modo il programmatore utilizzerà le funzioni associate alle classi per accedere al database senza dover per forza scrivere i comandi SQL corrispondenti. Questo semplifica molto il codice, anche se in alcuni casi può risultare limitante. Ma perché Flask non fornisce un ORM dal momento che quasi tutte le applicazioni si interfacciano a un database? E’ la filosofia di Flask. Lo sviluppatore è libero di scegliere come interagire con il database senza nessuna imposizione da parte del framework.
Un’altra differenza significativa è l’utilizzo da parte di Django del modello Model-Template-View, aspetto che in Flask non è presente. Come detto in precedenza, l’uso di questo modello permette ai programmatori di partizionare il processo di sviluppo rendendo la struttura del codice più pulita e ben definita, e migliorando i tempi di sviluppo. Flask invece lascia libertà allo sviluppatore la scelta di come strutturare il codice. Questo comporta che il team di sviluppo debba decidere a priori come strutturare il progetto e definire le linee guide per una buona programmazione.
Per questi motivi Flask viene di solito scelto per siti di piccole e medie dimensioni, come forum e blog personali, per prototipi o per applicazioni a pagina singola (SPA). Django, invece, si adatta perfettamente a grandi progetti come siti di e-commerce, CMS e sistemi informativi aziendali.
Andiamo a vedere più nel dettaglio le varie differenze.
Database
Come detto in precedenza, Django include un potente ORM che supporta un certo numero di database relazionali (SQLite, PostgreSQL, MySQL e Oracle). L’ORM di Django fornisce supporto per generare e gestire le migrazioni di un database. Mediante l’uso di modelli (classi Python) è anche facile creare form e viste, rendendo questo framework per tutte le applicazioni web che devono svolgere operazioni CRUD (Create, Read, Update, Delete) sul database. Nei casi in cui si necessità la scrittura di query complesse, l’ORM non è però adatto. Stesso discorso vale per l’uso di database NoSQL. In quest’ultimo caso esistono alcuni progetti tra cui Django MongoDB Engine o Djongo.
Flask da completa invece da libertà su come gestire i dati. Nonostante ciò esistono diverse librerie a disposizione. Per i database relazionali è possibile usare ad esempio Flask-SQLAlchemy, mentre per MongoDB Flask-PyMongo.
In conclusione, se il progetto utilizzerà un database relazionale, Django è la scelta migliore poichè, grazie all’ORM, rende il tutto molto più facile. Se, tuttavia, state usando un database non relazionale, Django vi renderà la vita un pò più difficile. E’ possibile infatti che, a meno che non usiate Djongo, alcune funzionalità, tra cui il pannello da amministratore, la rappresentazioni in classi dei modelli e l’autenticazione, non saranno sfruttabili.
Diversamente con Flask avrete libertà di scegliere l’ORM o l’ODM (Object Document Mapper) che rispecchia la meglio le vostre esigenze. Il prezzo di questa libertà è una curva di apprendimento più ripida e il maggior rischio di introdurre errori.
Auth
La maggior parte delle applicazioni web richiede l’autenticazione da parte degli utenti ed, eventualmente, la gestione delle autorizzazioni, ossia cosa è permesso di fare all’utente. Django fornisce entrambe queste funzionalità insieme alla gestione degli account e al supporto per le sessioni. Flask fornisce solamente il supporto per le sessioni basate sui cookie. Per quanto riguarda la gestione degli account, dell’autenticazione e delle autorizzazioni potete usare Flask-Security.
Admin
Una funzionalità molto apprezzata di Django è il pannello di amministrazione. Non è nient’altro che un’applicazione web già inclusa nel core del framework che permette di eseguire rapidamente operazioni CRUD sui vostri modelli. Il tutto è abbastanza configurabile con poche linee di codice. Anche in questo caso, Flask non fornisce nulla di simile. Una possibilità è di usare l’estensione Flask-Admin. Questa libreria supporta un certo numero di backend di database, come SQLAlchemy, Peewee, MongoEngine e PyMongo, che possono essere estesi con i vostri backend personali.
Routing e viste
Entrambi i framework permettono di mappare le URL alle viste, le quali sono basate su funzioni e classi.
In Django la definizione delle URL e delle viste avviene in file separati urls.py e views.py, rispettivamente. Quando una richiesta corrisponde a alla definizione di una URL, l’oggetto request, che contiene le informazioni della richiesta HTTP, viene passato alla vista corrispondente. La vista implementerà la business logic relativa e si occuperà di invocare il rendering del template corretto. Rimandiamo alla documentazione ufficiale per maggiori dettagli.
Rispetto a Django, l’oggetto request è globale in Flask, quindi è possibile accedervi molto più facilmente (a patto di importarlo). Le URL sono generalmente definiti insieme alla vista (tramite un decoratore), ma possono essere separati in una posizione centralizzata simile al modello Django.
Forms
Django fornisce una gestione integrata dei forms. Ciò include la gestione degli input, la validazione dei dati lato client e server. Inoltre sono affrontati vari problemi di sicurezza tra cui la falsificazione delle richieste cross-site (CSRF), lo scripting cross-site (XSS) e il SQL injection.
Come per altre funzionalità, Flask non supporta i form di default. Potete però usare l’estensione Flask-WTF che integra WTForms in Flask.
Componenti riutilizzabili
Dal momento che entrambi i progetti sono basati su Python, è possibile strutturare le applicazioni in modo tale da riutilizzare i componenti implementati.
Django usa il concetto delle app. Mediante il comando django-admin è possibile far creare dal framework una struttura base di un’app. Questa al suo interno avrà una struttura ben definita per ospitare il codice delle viste. Basterà aggiungere il file urls.py e la cartella dei template per gestire opportunamente le viste e il rendering delle pagine.
Flask usa invece il concetto dei blueprints. Sono molto più semplici e facili da utilizzare. Ovviamente la loro semplicità implica un maggiore sforzo da parte del programmatore a gestire e implementare le funzionalità ad essi associati.
Template e file statici
I template sono file html al cui interno è possibile iniettare alcune informazioni dinamiche generate dal backend. Flask usa Jinja2 come impostazione predefinita, mentre Django ha il proprio motore per renderizzare i template. La sintassi e l’insieme di funzionalità tra le due modalità sono molto simili.
Entrambi i framework hanno anche il supporto per la gestione dei file statici. Django fornisce inoltre un comando per collezionare tutti i file statici usati dai vari componenti e salvarli in una posizione predefinita, utile per la messa in produzione dell’applicazione.
Viste asincrone
Flask non supporta le richieste asincrone, mentre questa funzionalità è stata introdotta in Django 3.1. In questo modo una vista può essere resa asincrona usando la parola chiave async. Non è possibile usare la funzionalità async quando si interagisce con l’ORM o si opera a livello di cache. Per utilizzare una chiamata sincrona all’interno di una funzione async è sufficiente usare il decoratore sync_to_async.
Un’altra possibilità di eseguire task asincroni è Celery. Questa libreria permette di creare un servizio di esecuzione di task asincroni anche molto complesso. L’integrazione con Django è altamente supportata e documentata.
Sicurezza
Django ha una protezione integrata contro una serie di possibili attacchi tra cui:
- Cross-site scripting (XSS). Gli attacchi XSS permettono ad un attaccante di iniettare script lato client nei browser. I template di Django proteggono l’applicazione dalla maggior parte degli attacchi XSS.
- Falsificazione della richiesta cross-site (CSRF). Gli attacchi CSRF permettono ad un utente malintenzionato di eseguire azioni utilizzando le credenziali di un altro utente. Django ha una protezione integrata contro la maggior parte degli attacchi CSRF. Ad esempio tutti le sottomissioni di dati da form devono includere il csrf token per essere accettate.
- SQL injection. E’ un attacco in cui un utente malintenzionato è in grado di eseguire istruzioni SQL su un database. I set di query di Django sono protetti da SQL injection poiché le query sono costruite utilizzando la parametrizzazione.
I continui aggiornamenti del framework sono orientati, oltre a fornire nuove funzionalità, a correggere eventuali vulnerabilità che vengono riscontrate.
Flask, invece, è un framework molto più piccolo e di conseguenza con minori vulnerabilità. E’ compito dello sviluppatore gestire eventuali vulnerabilità che possono emergere durante la programmazione delle funzionalità o l’integrazione di altre librerie. Ciò significa che Flask è solo più difficile da mantenere sicuro rispetto ad un progetto sviluppato in Django. Il livello di sicurezza però è molto simile.
Casi d’uso
Come detto in precedenza entrambi i framework sono molto popolari nella comunità di sviluppatori Python. Infatti, Django è stato pensato per lo sviluppo veloce di applicazioni web complesse, scalabili e mantenibili nel tempo. Diversamente, la semplicità di Flask permette la creazione di piccole o medie applicazioni molto velocemente. Proprio per questo aspetto viene spesso utilizzato per creare microservizi.
I progetti più popolari sviluppati in Django sono i seguenti:
I siti web ce invece usano Flask sono:
Quale framework scegliere?
Alla luce di quanto presentato la domanda sorge spontanea. Come al solito non esiste una risposta assoluta poiché tutto dipende dal vostro progetto.
Se siete alle prime armi nello sviluppo di un’applicazione web il consiglio è di usare Flask. Essendo molto semplice e flessibile vi permetterà di comprendere al meglio la gestione delle richieste, delle viste e il rendering dei template. Non avrete nessuna funzionalità aggiuntiva se non quelle introdotte dall’utilizzo di librerie di terze parti.
Se però il vostro progetto è più complesso, il consiglio è di usare Django. Pur non avendo un supporto di base per i database NoSQL, Django risulta un ottimo alleato per sviluppare applicazioni che operano con i database. Alcune funzionalità, quali il pannello di amministratore, la definizione dei form integrata con i modelli e la gestione dell’autenticazione e delle autorizzazioni vi permetterà di concentrare lo sviluppo sulle funzionalità caratterizzanti l’applicativo. Inoltre, ridurrete i tempi di sviluppo ed avrete un prodotto altamente affidabile anche nel tempo.
