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?
la source
flask-babelpour la prise en charge de plusieurs langues etflask-seasurfpour le support CSRF pour sécuriser mes formulaires.Réponses:
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.
la source
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.
la source
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.
la source
Je pense que le moteur d'application Google prend officiellement en charge le framework flask. Il existe un exemple de code et un didacticiel ici -> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855
la source
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.
la source