Flask vs webapp2 pour Google App Engine


116

Je lance une nouvelle application Google App Engine et envisage actuellement deux frameworks: Flask et 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 je n'aurai aucun problème avec lui.

Cependant, il y a beaucoup de bonnes critiques de Flask, j'aime vraiment son approche et tout ce que j'ai lu jusqu'à présent dans la documentation et je veux l'essayer. Mais je suis un peu préoccupé par les limitations auxquelles je peux faire face avec Flask.

La question est donc la suivante: connaissez-vous des problèmes, des problèmes de performances, des limitations (par exemple, système de routage, mécanisme d'autorisation intégré, etc.) que Flask pourrait apporter à l'application Google App Engine? Par «problème», je veux dire quelque chose que je ne peux pas contourner dans plusieurs lignes de code (ou toute quantité raisonnable de code et d'efforts) ou quelque chose qui est complètement impossible.

Et comme question de suivi: y a-t-il des fonctionnalités tueuses dans Flask qui, selon vous, peuvent m'épater et me faire l'utiliser malgré les problèmes auxquels je peux faire face?


Je ne connais pas grand chose à webapp2, mais j'utilise Flask depuis quelques mois et j'adore ça. J'ai trouvé des plugins flask qui m'ont vraiment aidé, par exemple flask-babelpour la prise en charge de plusieurs langues et flask-seasurfpour le support CSRF pour sécuriser mes formulaires.
ThePloki

Réponses:


138

Avertissement: je suis l'auteur de tipfy et webapp2.

Un gros avantage de s'en tenir à webapp (ou à son évolution naturelle, webapp2) est que vous n'avez pas à créer vos propres versions pour les gestionnaires de 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 l'implémenter différé (comme je l'ai fait ici pour tipfy).

La même chose se produit pour les autres gestionnaires: blobstore (Werkzeug ne prend toujours pas en charge les requêtes de plage, vous devrez donc utiliser WebOb même si vous créez votre propre gestionnaire - voir tipfy.appengine.blobstore ), mail, XMPP et ainsi de suite, ou d'autres qui seront inclus dans le SDK à l'avenir.

Et la même chose se produit pour les bibliothèques créées avec App Engine à l'esprit, comme ProtoRPC , qui est basé sur webapp et aurait besoin d'un port ou d'un adaptateur pour fonctionner avec d'autres frameworks, si vous ne voulez pas mélanger webapp et votre-framework-of- gestionnaires de choix dans la même application.

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

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

Une défense webapp2 spécifique est résumée ici . Ajoutez à ceux que webapp2 peut être utilisé en dehors d'App Engine et qu'il est facile à personnaliser pour ressembler à des micro-frameworks populaires et vous avez un bon ensemble de raisons convaincantes d'y aller. De plus, webapp2 a de grandes chances 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 contributions.

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


10
Merci, @moraes! Assez solide. Je pense que des choses telles que le blobstore, le courrier (et probablement ProtoRPC) sont des éléments assez importants pour ce projet, et je veux travailler avec eux aussi facilement que possible. De plus, je pense que mélanger différents frameworks n'est pas la meilleure idée si vous pouvez facilement l'éviter. De plus, malgré le fait que je sympathise avec Flask, je suis vraiment impressionné par webapp2 et j'ai envie de l'essayer. Merci pour la réponse et pour webapp2!
Anton Moiseev

3
@Sundar Il peut fonctionner sur n'importe quel serveur Web compatible WSGI. Pour Apache, il y a code.google.com/p/modwsgi et d'autres.
moraes

4
@moraes: Cette réponse est-elle obsolète maintenant? Je peux voir que GAE SDK prend en charge Flask. Webapp2 est-il toujours le meilleur choix?
nish

1
@nish, faites-vous référence au fait que GAE SDK prend officiellement en charge Flask?
enkash

15
Juste une note, bien que ce soit la réponse acceptée héritée, le développement webapp2 est mort. Je dirais que Flask est la voie à suivre.
Jesse

13

Votre question est extrêmement large, mais l'utilisation de Flask sur Google App Engine ne semble pas poser de gros problèmes.

Ce fil de discussion de liste de diffusion renvoie à 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/

Consultez également App Engine - Difficulté à accéder aux données Twitter - Flask , le clignotement des messages Flask échoue entre les redirections et Comment gérer les bibliothèques Python tierces avec Google App Engine? (virtualenv? pip?) pour les problèmes que les gens ont rencontrés avec Flask et Google App Engine.


7
Merci, @agf. J'ai déjà vu la plupart de ces articles, mais je pense que je suis plus intéressé par l'expérience personnelle. Je ne pense pas que la question soit si large, puisque je ne suis pas intéressé par une discussion complète ou des informations détaillées sur un problème, faites-moi simplement remarquer que ceci et cela sera difficile ou impossible à mettre en œuvre.
Anton Moiseev

2
@Anton, Demander une expérience personnelle subjective est assez proche des directives SO pour les questions à ne pas poser .
James

9
@James - Je ne suis pas d'accord. Je ne vous pose pas de questions sur vos suppositions, vos suppositions ou vos sentiments subjectifs. Je vous pose des questions sur votre expérience, c'est-à-dire sur les faits que vous connaissez avec confiance. Pas de messages obsolètes, ni de problèmes auxquels d'autres personnes ont été confrontées lors de la personnalisation intensive, juste des faits. Ne soyez pas d'accord - d'accord, signalez-le simplement.
Anton Moiseev

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 orienté objet pur. webapp2 utilise le Method Based Dispatching comme standard pour tous les RequestHandlers (comme l'appelle la documentation de flask et l'implémente depuis la V0.7 dans MethodViews). Alors que dans flask, MethodViews est un add-on, c'est un principe de conception de base pour webapp2. Ainsi, la conception de votre logiciel sera différente en utilisant les deux frameworks. Les deux frameworks utilisent de nos jours des modèles jinja2 et sont assez identiques.

Je préfère ajouter des contrôles de sécurité à un RequestHandler de classe de base et en hériter. C'est également bon pour les 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 recommanderais webapp2 pour vous. Si vous préférez des fonctions simples avec des décorateurs comme gestionnaires pour plusieurs types de requêtes, ou si vous n'êtes pas à l'aise avec l'héritage OO, choisissez flask. Je pense que les deux frameworks évitent la complexité et les dépendances de frameworks beaucoup plus grands comme la pyramide.

  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

ça y est, le support OOP m'a gagné. J'utilise à l'origine web.py mais webapp2 semble avoir une structure soignée sans solution de contournement que j'ai faite sur web.py. flask peut être facile à démarrer, mais vous avez besoin de plus que cela si vous prévoyez de créer de plus grandes applications
Ahmad Muzakki


2

Je n'ai pas essayé webapp2 et j'ai trouvé que tipfy était un peu difficile à utiliser car il nécessitait des scripts de configuration et des builds qui configurent votre installation python sur une autre valeur que celle par défaut. Pour ces raisons et d'autres, je n'ai pas fait dépendre mon plus gros projet d'un framework et j'utilise plutôt l'application web simple, ajoutez 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 lors de la construction d'un l'application localisée django était le bon choix pour mon plus grand projet. Les 2 autres frameworks que j'ai effectivement déployés avec des projets dans un environnement de production étaient GAEframework.com et web2py et il semble généralement que l'ajout d'un framework qui change son moteur de template pourrait conduire à des incompatibilités entre les anciennes et les nouvelles versions.

Donc, mon expérience est que je suis réticent à ajouter un framework à mes projets à moins qu'ils ne résolvent les cas d'utilisation plus avancés (téléchargement de fichier, multi auth, interface utilisateur sont 3 exemples de cas d'utilisation plus avancés qu'aucun framework pour gae pour le moment gère bien.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.