Flask vs webapp2 pour Google App Engine

Question

Je démarre une nouvelle application Google App Engine et je considère actuellement deux frameworks : Flacon y webapp2 . Je suis plutôt satisfait du framework webapp intégré que j'ai utilisé pour ma précédente application App Engine, donc je pense que webapp2 sera encore meilleur et que je n'aurai aucun problème avec lui.

Cependant, il y a beaucoup de bonnes critiques sur Flask, j'aime vraiment son approche et toutes les choses que j'ai lues jusqu'à présent dans la documentation et j'ai envie de l'essayer. Mais je suis un peu préoccupé par les limitations auxquelles je peux être confronté avec Flask.

La question est donc - Connaissez-vous des problèmes, des problèmes de performance, des limitations (par exemple, le système de routage, le mécanisme d'autorisation intégré, etc.) que Flask pourrait apporter à l'application Google App Engine ? Par "problème", j'entends quelque chose que je ne peux pas résoudre en quelques lignes de code (ou toute quantité raisonnable de code et d'efforts) ou quelque chose qui est complètement impossible.

Et en guise de question complémentaire : y a-t-il des fonctionnalités phares dans Flask qui, selon vous, pourraient me faire changer d'avis et m'inciter à l'utiliser malgré les problèmes auxquels je pourrais être confronté ?

Answer 1

Avis de non-responsabilité : Je suis l'auteur de tipfy et webapp2.

Un grand avantage de s'en tenir à webapp (ou à son évolution naturelle, webapp2) est que vous n'avez pas à créer vos propres versions des gestionnaires SDK existants pour le framework de votre choix.

Par exemple, différé utilise un gestionnaire d'application web. Pour l'utiliser dans une vue Flask pure, en utilisant werkzeug.Request et werkzeug.Response, vous devrez implémenter deferred pour elle (comme je l'ai fait aquí pour tipfy).

Il en va de même pour les autres gestionnaires : blobstore (Werkzeug ne prend toujours pas en charge les demandes d'intervalle, vous devrez donc utiliser WebOb même si vous créez votre propre gestionnaire -- voir tipfy.appengine.blobstore ), mail, XMPP, etc., ou d'autres qui seront inclus dans le SDK à l'avenir.

Il en va de même pour les bibliothèques créées pour App Engine, telles que ProtoRPC qui est basé sur webapp et aurait besoin d'un portage ou d'un adaptateur pour fonctionner avec d'autres frameworks, si vous ne voulez pas mélanger webapp et les gestionnaires de votre cadre de travail de choix dans la même application.

Ainsi, même si vous choisissez un framework différent, vous finirez par a) utiliser webapp dans certains cas particuliers ou b) devoir créer et maintenir vos versions pour des gestionnaires ou des fonctionnalités spécifiques du SDK, si vous les utilisez.

Je préfère de loin Werkzeug à WebOb, mais après plus d'un an de portage et de maintenance des versions des gestionnaires du SDK qui fonctionnent nativement avec tipfy, j'ai réalisé que c'est une cause perdue -- pour soutenir GAE à long terme, le mieux est de rester proche de webapp/WebOb. Cela facilite le support des bibliothèques SDK, la maintenance devient beaucoup plus facile, c'est plus à l'épreuve du temps car les nouvelles bibliothèques et fonctionnalités SDK fonctionneront dès le départ et il y a l'avantage d'une grande communauté travaillant autour des mêmes outils App Engine.

Une défense spécifique de webapp2 est résumée aquí . S'ajoutent à cela webapp2 peut être utilisé en dehors d'App Engine et est facile à personnaliser pour ressembler aux micro-frameworks les plus répandus et vous avez de bonnes raisons de le faire. De plus, webapp2 a une grande chance d'être inclus dans une future version du SDK (c'est extra-officiel, ne me citez pas :-) ce qui le fera avancer et apportera de nouveaux développeurs et de nouvelles contributions.

Cela dit, je suis un grand fan de Werkzeug et des gars de Pocoo et j'ai beaucoup emprunté à Flask et à d'autres (web.py, Tornado), mais -- et, vous savez, je suis partial -- les avantages de webapp2 mentionnés ci-dessus devraient être pris en compte.

Answer 2

Votre question est extrêmement vaste, mais il semble qu'il n'y ait pas de problème majeur à utiliser Flask sur Google App Engine.

Cette liste de diffusion contient des liens vers plusieurs modèles :

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

Et voici un tutoriel spécifique à la combinaison Flask / App Engine :

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

Voir aussi App Engine - Difficulté d'accès aux données Twitter - Flask , Le clignotement des messages Flask échoue à travers les redirections y Comment gérer les bibliothèques Python tierces avec Google App Engine (virtualenv ? pip ?)? pour les problèmes rencontrés avec Flask et Google App Engine.

Answer 3

Pour moi, la décision pour webapp2 a été facile lorsque j'ai découvert que flask n'est pas un framework orienté objet (depuis le début), alors que webapp2 est un framework purement orienté objet. webapp2 utilise le Method Based Dispatching comme standard pour tous les RequestHandlers (comme la documentation de flask l'appelle et l'implémente depuis la V0.7 dans les MethodViews). Alors que dans Flask les MethodViews sont un ajout, c'est un principe de conception fondamental pour webapp2. Ainsi, la conception de votre logiciel sera différente en utilisant les deux frameworks. Les deux frameworks utilisent aujourd'hui les templates de jinja2 et sont relativement identiques en termes de fonctionnalités.

Je préfère ajouter des contrôles de sécurité à une classe de base RequestHandler et en hériter. Cela convient également aux fonctions utilitaires, etc. Comme vous pouvez le voir par exemple dans le lien [3], vous pouvez surcharger les méthodes pour empêcher l'envoi d'une requête.

Si vous êtes une personne OO, ou si vous avez besoin de concevoir un serveur REST, je vous recommande webapp2. Si vous préférez des fonctions simples avec des décorateurs pour gérer plusieurs types de requêtes, ou si vous n'êtes pas à l'aise avec l'héritage OO, alors choisissez flask. Je pense que ces deux frameworks évitent la complexité et les dépendances de frameworks beaucoup plus importants comme pyramid.

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

Answer 4

Je n'ai pas essayé webapp2 et j'ai trouvé que tipfy était un peu difficile à utiliser car il nécessitait des setup scripts et des builds qui configurent votre installation python autrement que par défaut. Pour ces raisons et d'autres, je n'ai pas fait dépendre mon plus grand projet d'un framework et j'utilise plutôt la simple webapp, j'ajoute la bibliothèque appelée beaker pour obtenir la capacité de session et django a déjà des traductions intégrées pour les mots communs à de nombreux cas d'utilisation, donc pour construire une application localisée, django était le bon choix pour mon plus grand projet. Les 2 autres frameworks que j'ai déployés avec des projets dans un environnement de production étaient GAEframework.com et web2py et en général il semble que l'ajout d'un framework qui change son moteur de template pourrait conduire à des incompatibilités entre l'ancienne et la nouvelle version.

Mon expérience est donc que je suis réticent à ajouter un framework à mes projets à moins qu'ils ne résolvent les cas d'utilisation les plus avancés (le téléchargement de fichiers, l'authentification multiple, l'interface d'administration sont 3 exemples de cas d'utilisation plus avancés qu'aucun framework pour gae ne gère bien pour le moment).

Answer 5

Je pense que google app engine supporte officiellement le framework flask. Il y a un exemple de code et un tutoriel ici -> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855