Flask vs webapp2 per Google App Engine

Sto avviando una nuova applicazione Google App Engine e attualmente sto considerando due framework: Flask e webapp2 . Sono piuttosto soddisfatto del framework webapp integrato che ho usato per la mia precedente applicazione App Engine, quindi penso che webapp2 sarà ancora migliore e non avrò alcun problema con esso.

Tuttavia, ci sono molte buone recensioni di Flask, mi piace molto il suo approccio e tutte le cose che ho letto finora nella documentazione e voglio provarlo. Ma sono un po 'preoccupato per i limiti che posso affrontare lungo la strada con Flask.

Quindi, la domanda è: conosci problemi, problemi di prestazioni, limitazioni (ad es. Sistema di routing, meccanismo di autorizzazione integrato, ecc.) Che Flask potrebbe portare nell'applicazione Google App Engine? Per "problema" intendo qualcosa che non posso aggirare in diverse righe di codice (o una quantità ragionevole di codice e sforzi) o qualcosa che è completamente impossibile.

E come domanda di follow-up: ci sono delle caratteristiche killer in Flask che pensi possano farmi impazzire e farmi usare nonostante i problemi che posso affrontare?

Disclaimer: sono l'autore di tipfy e webapp2.

Un grande vantaggio di restare fedeli a webapp (o alla sua naturale evoluzione, webapp2) è che non è necessario creare le proprie versioni per i gestori SDK esistenti per il framework di propria scelta.

Ad esempio, deferred utilizza un gestore di webapp. Per usarlo in una visualizzazione Flask pura, usando werkzeug.Request e werkzeug.Response, dovrai implementare differito per esso (come ho fatto qui per tipfy).

Lo stesso accade per altri gestori: blobstore (Werkzeug non supporta ancora le richieste di intervallo, quindi dovrai usare WebOb anche se crei il tuo gestore - vedi tipfy.appengine.blobstore ), mail, XMPP e così via, o altri che saranno inclusi nell'SDK in futuro.

E lo stesso accade per le librerie create pensando ad App Engine, come ProtoRPC , che è basato su webapp e avrebbe bisogno di una porta o di un adattatore per funzionare con altri framework, se non vuoi mischiare webapp e il tuo framework di gestori di scelta nella stessa app.

Quindi, anche se scegli un framework diverso, finirai a) utilizzare webapp in alcuni casi speciali o b) dover creare e mantenere le tue versioni per gestori o funzionalità SDK specifici, se li utilizzerai.

Preferisco di gran lunga Werkzeug su WebOb, ma dopo oltre un anno di porting e mantenimento di versioni dei gestori SDK che funzionano in modo nativo con tipfy, mi sono reso conto che questa è una causa persa: per supportare GAE a lungo termine, la cosa migliore è rimanerci vicino webapp / WebOb. Rende il supporto per le librerie SDK un gioco da ragazzi, la manutenzione diventa molto più semplice, è più a prova di futuro poiché le nuove librerie e le funzionalità SDK funzioneranno immediatamente e c'è il vantaggio di una grande comunità che lavora sugli stessi strumenti di App Engine.

Una specifica difesa webapp2 è riassunta qui . Aggiungi a quelli che webapp2 può essere utilizzata al di fuori di App Engine ed è facile da personalizzare per assomigliare a popolari micro-framework e hai una buona serie di validi motivi per farlo. Inoltre, webapp2 ha una grande possibilità di essere inclusa in una futura versione dell'SDK (questo è extra-ufficiale, non citarmi :-) che lo spingerà avanti e porterà nuovi sviluppatori e contributi.

Detto questo, sono un grande fan di Werkzeug e dei ragazzi di Pocoo e ho preso molto in prestito da Flask e altri (web.py, Tornado), ma - e, sai, sono di parte - i vantaggi di webapp2 di cui sopra dovrebbero essere preso in considerazione.

La tua domanda è estremamente ampia, ma sembra che non ci siano grossi problemi nell'utilizzo di Flask su Google App Engine.

Questo thread della mailing list si collega a diversi modelli:

http://flask.pocoo.org/mailinglist/archive/2011/3/27/google-app-engine/#4f95bab1627a24922c60ad1d0a0a8e44

Ed ecco un tutorial specifico per la combinazione Flask / App Engine:

http://www.franciscosouza.com/2010/08/flying-with-flask-on-google-app-engine/

Inoltre, consulta App Engine - Difficoltà di accesso ai dati di Twitter - Flask , il lampeggiamento del messaggio Flask non riesce tra i reindirizzamenti e Come si gestiscono le librerie Python di terze parti con Google App Engine? (virtualenv? pip?) per problemi che le persone hanno avuto con Flask e Google App Engine.

Per me la decisione per webapp2 è stata facile quando ho scoperto che flask non è un framework orientato agli oggetti (dall'inizio), mentre webapp2 è un puro framework orientato agli oggetti. webapp2 utilizza il dispacciamento basato sul metodo come standard per tutti i RequestHandlers (come la documentazione del flask lo chiama e lo implementa dalla V0.7 in MethodViews). Sebbene in flask MethodViews sia un componente aggiuntivo, è un principio di progettazione fondamentale per webapp2. Quindi il design del software apparirà diverso utilizzando entrambi i framework. Entrambi i framework utilizzano oggigiorno i modelli jinja2 e sono abbastanza identici.

Preferisco aggiungere controlli di sicurezza a un RequestHandler di classe base ed ereditarne uno. Questo è utile anche per le funzioni di utilità, ecc. Come puoi vedere ad esempio nel link [3] puoi sovrascrivere i metodi per impedire l'invio di una richiesta.

Se sei una persona OO, o se hai bisogno di progettare un server REST, ti consiglierei webapp2. Se preferisci funzioni semplici con decoratori come gestori di più tipi di richiesta, o non ti senti a tuo agio con l'ereditarietà OO, scegli flask. Penso che entrambi i framework evitino la complessità e le dipendenze di framework molto più grandi come la piramide.

1. http://flask.pocoo.org/docs/0.10/views/#method-based-dispatching
2. https://webapp-improved.appspot.com/guide/handlers.html
3. https://webapp-improved.appspot.com/guide/handlers.html#overriding-dispatch

Penso che il motore dell'app Google supporti ufficialmente il framework flask. C'è un codice di esempio e un tutorial qui -> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855

Non ho provato webapp2 e ho scoperto che tipfy era un po 'difficile da usare poiché richiedeva script di installazione e build che configurano l'installazione di Python su valori diversi da quelli predefiniti. Per questi e altri motivi non ho fatto dipendere il mio progetto più grande da un framework e invece utilizzo la semplice webapp, aggiungo la libreria chiamata beaker per ottenere capacità di sessione e django ha già traduzioni integrate per parole comuni a molti casi d'uso, quindi quando si crea un l'applicazione localizzata django è stata la scelta giusta per il mio progetto più grande. Gli altri 2 framework che ho effettivamente distribuito con progetti in un ambiente di produzione erano GAEframework.com e web2py e in generale sembra che l'aggiunta di un framework che modifica il suo motore di modelli possa portare a incompatibilità tra le vecchie e le nuove versioni.

Quindi la mia esperienza è che sono riluttante ad aggiungere un framework ai miei progetti a meno che non risolvano i casi d'uso più avanzati (caricamento di file, multi autenticazione, interfaccia utente di amministrazione sono 3 esempi di casi d'uso più avanzati che nessun framework per gae al momento gestisce bene.