Flask, un piccolo framework con le idee molto chiare

Scritto in Python, è uno strumento molto flessibile per realizzare infrastrutture complesse e performanti

Flask è un framework scritto in Python, basato su Werkzeug e Jinja2; il primo è una libreria per la gestione del protocollo WSGI, mentre il secondo è un motore di templating molto utilizzato e performante.

L’aggettivo che descrive meglio Flask, a detta degli stessi sviluppatori, è “micro”, con il quale non si intende tracciare i limiti del framework bensì il suo essere essenziale; nonostante sia decisamente snello, offre una vasta serie di “punti di aggancio” (hook, in gergo) che consentono di personalizzarne le funzionalità secondo le proprie esigenze. La comunità non è ovviamente paragonabile a quelle di altre prodotti ben più blasonati, ma ha già sfornato una serie di estensioni fondamentali per chi decide di usarlo per i suoi progetti; inoltre, il core team vaglia attentamente tutto ciò che viene prodotto e rilasciato dalla comunità per garantire (nei limiti del possibile, ovviamente) che nessuna estensione si riveli disruptive, e cioè vada ad inficiare il funzionamento delle versioni stabili del framework.

Flask non è uno strumento da usare “as-is”, non è qualcosa da installare e via, e non è qualcosa che offrirà soluzioni a problemi che non abbiamo affrontato, come i tanti framework orientati agli utenti che sono disponibili in giro: usare una tecnologia di ORM, abilitare gli utenti ad usare funzionalità della piattaforma in virtù di una qualche matrice permessi-ruoli, applicare politiche di caching a specifiche URL, sono cose che possiamo fare soltanto se abbiamo espressamente predisposto il software a fare ciò.

Per questi compiti Flask non offre alcuna soluzione preconfezionata all’interno del codice base del framework, ma mette a disposizione tutti gli strumenti per poter creare la soluzione che meglio risolve i problemi del caso. Dalla documentazione ufficiale:

 

“As your codebase grows, you are free to make the design decisions appropriate for your project. Flask will continue to provide a very simple glue layer to the best that Python has to offer. You can implement advanced patterns in SQLAlchemy or another database tool, introduce non-relational data persistence as appropriate, and take advantage of framework-agnostic tools built for WSGI, the Python web interface.”

 

A questo punto dovrebbe essere chiaro che in Flask quello che serve va creato (come già detto esiste una serie di estensioni che facilitano il compito; le trovate qui), e lo si deve creare tenendo ben presente tutti gli aspetti che possono essere coinvolti, come ad esempio sicurezza e performance. E se è chiaro ciò, e se lo si può affrontare (perchè sicuramente è un “costo” a livello di project management) , dovrebbe essere chiaro anche il fatto che Flask rappresenta uno strumento (sicuramente non l’unico) con il quale si possono creare applicazioni web, magari di taglio enterprise, estremamente verticali, ottimizzate, modulari, estensibili (ad esempio attraverso l’implementazione di api RESTful) e soprattutto con il quale si possono integrare agevolmente diverse tecnologie senza incorrere nei vincoli che framework più complessi costringono a rispettare.

 

Un’ottima documentazione

 

Chiunque si avvicini a Flask per la prima volta nota da subito che la documentazione è molto ben curata, e ne apprezza l’impostazione, orientata a prendere per mano sia l’utente novizio che quello esperto mostrando i vari aspetti del framework, siano essi di livello introduttivo oppure problematiche di deployment avanzate. Quest’ultima considerazione è indicativa della natura di Flask: in bella mostra in una delle prime pagine, fanno capolino paragrafi importanti, contenenti informazioni come il deployment su Heroku o Google App Engine, piuttosto che suggerimenti circa il deployment tramite Fabric, oppure il dispatching di diverse istanze della stessa applicazione (ma magari con configurazioni differenti) in corrispondenza di diverse URL; tutte problematiche generalmente affrontate in fase di rilascio di soluzioni abbastanza complesse.

 

Infine, la documentazione è scaricabile in diversi formati (PDF, ePub, .mobi), consultabile quindi anche offline.

 

Design

 

Un’altra esperienza interessante è scoprire poco a poco quali sono le best practice con le quali scrivere la vostra applicazione: a partire dal buon vecchio esempio “Hello World!” si passa per i concetti di modularizzazione attraverso le Blueprint, scoprendo le Application Factories (una tecnica per istanziare la stessa applicazione ma con una configurazione differente, ad esempio puntando ad un altro DBMS), oppure gli Application Dispatchers, che consentono di combinare letteralmente insieme, a livello di WSGI, due o più applicazioni, anche differenti, ad esempio Django e Flask.

 

In sintesi, ne vale la pena ?

 

A mio parere, le considerazioni da fare per capire se l’effort dell’adozione di Flask in un progetto è giustificato sono diverse.

Il primo, più importante, è rappresentato dalla confidenza del gruppo di lavoro con altri framework. 

Mi spiego: in Abstract, dove da ormai 7 anni adoperiamo Zope & Plone e da 3 Django/Satchmo, scegliere una di queste due soluzioni ci garantisce una velocità di intervento e una risolutezza nello sviluppo che difficilmente possono essere eguagliate con l’adozione di altri framework, per cui spesso possiamo decidere, da un punto di vista di valutazione del costo, di adoperarli per produrre quasi qualunque tipo di soluzione, anche in casi in cui lo strumento può rivelarsi sovradimensionato rispetto al problema.

Abbiamo però già fatto esperienze in cui soluzioni “pronte”, come appunto potrebbe essere Plone, mostrano il fianco o per motivi di flessibilità, o per necessità di integrazione spinta, o per esigenze di scalabilità in produzione. In queste progetti, integrare software troppo eterogenei può determinare (e questa eventualità spesso si verifica) la presenza di "punti di stress" che possono causare un collo di bottiglia non indifferente per l'intera architettura, se non il collasso strutturale della piattaforma.

Ecco quindi che l’adozione di una soluzione come Flask obbliga ad aumentare il costo in termini di tempo e/o risorse necessarie, ma non introduce vincoli tecnici particolarmente critici, e permette di "spingere" nella direzione desiderata.

Proprio in Abstract abbiamo dei progetti in cantiere relativi a piattaforme di Continuous Integration e Continuous Deployment pensati e costruiti intorno a strumenti come Flask (o Tornado), e che hanno assolutamente bisogno di tali strumenti (da intendere quasi come “glue tools”) per poter conservare la flessibililtà necessaria al raggiungimento dell’obiettivo.

 

Segnalo che ad EuroPython saranno presenti alcuni talk relativi a Flask. Ci vediamo a Firenze !

 

Share this on

Share |

On same topics

Commenti

comments powered by Disqus