Flask vs webapp2 pour Google App Engine

Question

Je commence 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 ça.

Cependant, il y a beaucoup de bonnes critiques de Flask, j'aime vraiment son approche et tout ce que j'ai lu jusqu'à maintenant dans la documentation et je veux l'essayer. Mais je suis un peu préoccupé par les limites que je peux affronter avec Flask. Donc, la question est - 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 dans 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 en guise de question de suivi: est-ce qu'il y a des caractéristiques tueuses dans Flask qui, selon moi, peuvent me bouleverser et me faire utiliser malgré tous les problèmes auxquels je peux faire face?

Answer 1

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

Un gros avantage de coller avec webapp (ou son évolution naturelle, webapp2) est que vous n'avez pas besoin de créer vos propres versions pour les gestionnaires de SDK existants pour votre framework de votre choix. Par exemple, deferred utilise un gestionnaire WebApp. Pour l'utiliser dans une vue Flask pure, en utilisant werkzeug.Request et werkzeug.Response, vous devrez implémenter différé pour cela (comme je l'ai fait here pour tipfy). Il en va de même pour les autres gestionnaires: blobstore (Werkzeug ne prend toujours pas en charge les requêtes de plage, donc vous devrez 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 sont inclus dans le SDK à l'avenir.

Et la même chose se produit pour les bibliothèques créées avec App Engine, 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 mixer webapp et ... cadres de choix dans la même application. Donc, même si vous choisissez un framework différent, vous finirez a) en utilisant webapp dans certains cas particuliers ou b) en ayant à créer et à maintenir vos versions pour des gestionnaires de SDK ou des fonctionnalités spécifiques, si vous les utilisez.Je préfère de loin 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 à long terme, le mieux est rester proche de webapp/WebOb. Il simplifie la prise en charge des librairies SDK, la maintenance devient beaucoup plus facile, elle est plus pérenne car les nouvelles librairies et les fonctionnalités du SDK fonctionneront immédiatement et une grande communauté travaillant avec les mêmes outils App Engine bénéficiera des avantages.

Une défense webapp2 spécifique est résumée here. Ajouter à ceux que webapp2 can be used outside of App Engine et est easy to be customized to look like popular micro-frameworks et vous avez un bon ensemble de raisons impérieuses d'y aller. En outre, webapp2 a de grandes chances d'être inclus dans une future version du SDK (c'est extra-officiel, ne me citez pas :-) qui va le faire avancer et amener de nouveaux développeurs et 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 - le Au-dessus de webapp2 avantages devraient être pris en compte.

Answer 2

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

Cette liste de diffusion des liens de fil à plusieurs modèles:

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

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

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

Aussi, voir App Engine - Difficulty Accessing Twitter Data - Flask, Flask message flashing fails across redirects, et How do I manage third-party Python libraries with Google App Engine? (virtualenv? pip?) pour les problèmes que les gens ont eu avec Flask et Google App Engine.

Answer 3

Je n'ai pas essayé webapp2 et j'ai trouvé que tipfy était un peu difficile à utiliser car il nécessitait des scripts d'installation et des compilations qui configurent votre installation python autrement que par défaut. Pour ces raisons et d'autres, je n'ai pas fait de mon plus grand projet dépend d'un framework et j'utilise à la place la webapp simple, ajoute la bibliothèque appelée beaker pour obtenir la capacité de session et django a déjà intégré des traductions pour des mots communs à beaucoup d'usecases application localisée django était le bon choix pour mon plus grand projet. Les deux autres frameworks que j'ai réellement 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 cadre à mes projets à moins qu'ils ne résolvent les cas d'utilisation plus avancés (téléchargement de fichiers, multi auth, admin ui sont 3 exemples de cas d'utilisation plus avancés qu'aucun cadre pour Gae au moment gère bien

Answer 4

Je pense que le moteur Google app supporte officiellement le cadre de flacon Il est un exemple de code et tutoriel ici -..>https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855

Answer 5

pour moi, la décision de webapp2 était facile quand j'ai découvert que flacon est n'est pas un framework orienté objet (depuis le début), alors que webapp2 est un framework orienté objet pur.webapp2 utilise le Dispatching basé sur la méthode comme standard pour toutes les requêtes. andlers (comme la documentation de flask l'appelle et l'implémente depuis V0.7 dans MethodViews). Alors que dans la fiole MethodViews sont un add-on, c'est un principe de conception de base pour webapp2. Donc, la conception de votre logiciel sera différente en utilisant les deux frameworks. Les deux frameworks utilisent de nos jours les templates jinja2 et sont assez similaires.

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 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 en tant que 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 cadres évitent la complexité et les dépendances de cadres 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