Flask vs webapp2 pour Google App Engine
je commence une nouvelle application Google App Engine et envisage actuellement deux cadres: flacon et webapp2 . Je suis plutôt satisfait du cadre webapp intégré que j'ai utilisé pour ma précédente application App Engine, donc je pense que webapp2 sera encore mieux et je n'aurai aucun problème avec elle.
cependant, il ya beaucoup de bonnes critiques de Flask, j'aime vraiment son approche et toutes les choses que j'ai lu jusqu'à présent dans la documentation et je veux l'essayer. Mais je suis un peu préoccupé par les limites que je peux affronter sur la route avec flasque.
donc, la question Est - connaissez-vous des problèmes, des problèmes de performance, des limites (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 travailler autour de plusieurs lignes de code (ou tout montant raisonnable de code et d'efforts) ou quelque chose qui est complètement impossible.
et comme une question de suivi: y a-t-il des caractéristiques tueuses dans flasque que vous pensez peut souffler mon esprit et me faire l'utiliser en dépit de tous les problèmes que je peux faire face?
5 réponses
Avertissement: je suis l'auteur de tipfy et webapp2.
un grand avantage de rester avec webapp (ou son évolution naturelle, webapp2) est que vous n'avez pas à créer vos propres versions pour les gestionnaires SDK existants pour votre cadre de votre choix.
Par exemple, différé", 151980920" utilise une webapp gestionnaire. Pour l'utiliser dans une vue flasque pure, en utilisant werkzeug.Demande et werkzeug.La réponse, vous aurez besoin de mise en œuvre reportée pour elle (comme je l'ai fait ici pour tipfy).
il en va de même pour les autres handlers: blobstore (Werkzeug ne supporte toujours pas les requêtes de portée, donc vous devrez utiliser WebOb même si vous créez votre propre handler -- voir tipfy.appengine.blobstore ), mail, XMPP et ainsi de suite, ou d'autres qui sont inclus dans le SDK à l'avenir.
et la même chose se produit pour les bibliothèques créées avec le moteur D'application dans attention, comme ProtoRPC , qui est basé sur webapp et aurait besoin d'un port ou adaptateur pour travailler avec d'autres cadres, si vous ne voulez pas mélanger webapp et votre-framework-de-choix handlers dans la même application.
ainsi, même si vous choisissez un framework différent, vous finirez a) en utilisant webapp dans certains cas spéciaux ou b) en ayant à créer et à maintenir vos versions pour des gestionnaires ou des fonctionnalités SDK spécifiques, si vous les utilisez.
je préfère Werkzeug sur WebOb, mais après plus d'un an de portage et de maintenance des versions des gestionnaires SDK qui fonctionnent nativement avec tipfy, j'ai réalisé que c'est une cause perdue -- pour soutenir GAE pour le long terme, le mieux est de rester proche de webapp/WebOb. Il rend le soutien pour les bibliothèques SDK un jeu d'enfant, la maintenance devient beaucoup plus facile, il est plus à l'épreuve du futur que les nouvelles bibliothèques et les fonctionnalités SDK fonctionneront hors de la boîte et il y a l'avantage d'une grande communauté travaillant autour des mêmes outils de moteur D'application.
une défense webapp2 spécifique est résumée ici . Ajoutez à ceux que webapp2 peut être utilisé en dehors de L'App Engine et est facile à être personnalisé pour ressembler à des micro-cadres populaires et vous avez un bon ensemble de raisons convaincantes pour aller pour elle. En outre, webapp2 a une grande chance d'être inclus dans une future version SDK (c'est extra-officiel, ne me cite pas :-) qui va le pousser en avant et apporter de nouvelles développeurs et contributions.
cela dit, je suis un grand fan de Werkzeug et les gars de Pocoo et emprunté beaucoup de 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.
votre question est extrêmement large, mais il ne semble pas y avoir de gros problèmes en utilisant flasque sur Google App Engine.
ce fil de discussion de liste de diffusion renvoie à plusieurs modèles:
Et voici un tutoriel spécifique à la combinaison moteur flasque / App:
http://www.franciscosouza.com/2010/08/flying-with-flask-on-google-app-engine /
voir Aussi App Engine - la Difficulté à Accéder aux Données de Twitter - Flacon , Flacon de message clignotant échoue au travers des redirections , et Comment puis-je gérer les tiers bibliothèques Python avec Google App Engine? (virtualenv? pip?) pour les questions que les gens ont eu avec la Fiole et Google App Engine.
pour moi, la décision pour webapp2 a été facile quand j'ai découvert que flask n'est pas un cadre orienté objet (dès le début), tandis que webapp2 est un cadre orienté objet pur. webapp2 utilise le Dispatching basé sur la méthode comme standard pour tous les RequestHandlers (comme la documentation de flasque l'appelle et l'implémente depuis V0.7 dans MethodViews). Tandis que dans flask MethodViews sont un add-on il est un principe de conception de base pour webapp2. Ainsi, votre conception de logiciel sera différente en utilisant les deux cadres. Les deux cadres 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 remplacer les méthodes pour empêcher l'envoi d'une demande.
si vous êtes une OO-personne, ou si vous avez besoin de concevoir un REST-server, je recommande webapp2 pour vous. Si vous préférez des fonctions simples avec décorateurs en tant que gestionnaires pour plusieurs types de demande, ou vous n'êtes pas à l'aise avec OO-héritage puis choisir flasque. Je pense que les deux cadres évitent la complexité et les dépendances des cadres beaucoup plus grands comme la pyramide.
je pense que google app engine supporte officiellement flask framework. Il y a un exemple de code et de tutoriel ici -> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855
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 constructions qui configurent votre installation python autrement que par défaut. Pour ces raisons et d'autres je n'ai pas fait mon plus grand projet dépend d'un cadre et j'utilise le webapp simple à la place, ajouter 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 usecases donc lors de la construction d'une application localisée django était le bon choix pour mon plus grand projet. Les 2 autres cadres que j'ai réellement 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 modifie 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 cadre à mes projets à moins qu'ils ne résolvent les cas d'utilisation plus avancés (téléchargement de fichiers, multi auth, interface d'administration sont 3 exemples de cas d'utilisation plus avancés qu'aucun cadre pour gae pour le moment gère bien.