Flask vs webapp2 für Google App Engine

Ich starte eine neue Google App Engine-Anwendung und erwäge derzeit zwei Frameworks: Flask und webapp2 . Ich bin ziemlich zufrieden mit dem integrierten Webapp-Framework, das ich für meine vorherige App Engine-Anwendung verwendet habe. Daher denke ich, dass webapp2 noch besser sein wird und ich keine Probleme damit haben werde.

Es gibt jedoch viele gute Bewertungen von Flask, ich mag seinen Ansatz und all die Dinge, die ich bisher in der Dokumentation gelesen habe und ich möchte es ausprobieren. Aber ich bin ein bisschen besorgt über die Einschränkungen, die ich mit Flask auf mich nehmen kann.

Die Frage ist also: Kennen Sie Probleme, Leistungsprobleme, Einschränkungen (z. B. Routing-System, integrierter Autorisierungsmechanismus usw.), die Flask in die Google App Engine-Anwendung einbringen könnte? Mit "Problem" meine ich etwas, das ich nicht in mehreren Codezeilen (oder einer angemessenen Menge an Code und Aufwand) umgehen kann, oder etwas, das völlig unmöglich ist.

Und als Folgefrage: Gibt es in Flask Killer-Features, von denen Sie glauben, dass sie mich umhauen und dazu bringen können, sie zu verwenden, trotz aller Probleme, mit denen ich konfrontiert werden kann?

Haftungsausschluss: Ich bin der Autor von tipfy und webapp2.

Ein großer Vorteil des Festhaltens an webapp (oder seiner natürlichen Entwicklung, webapp2) besteht darin, dass Sie keine eigenen Versionen für vorhandene SDK-Handler für das Framework Ihrer Wahl erstellen müssen.

Zum Beispiel latenten verwenden einen Webapp - Handler. Um es in einer reinen Flask-Ansicht mit werkzeug.Request und werkzeug.Response zu verwenden, müssen Sie es verzögert implementieren (wie ich es hier für tipfy getan habe).

Das Gleiche gilt für andere Handler: blobstore (Werkzeug unterstützt immer noch keine Bereichsanforderungen, daher müssen Sie WebOb verwenden, auch wenn Sie einen eigenen Handler erstellen - siehe tipfy.appengine.blobstore ), mail, XMPP usw. oder andere, die in Zukunft im SDK enthalten sind.

Das Gleiche gilt für Bibliotheken, die mit Blick auf App Engine erstellt wurden, wie ProtoRPC , das auf Webapp basiert und einen Port oder Adapter benötigt, um mit anderen Frameworks zu arbeiten, wenn Sie Webapp und Ihr Framework of nicht mischen möchten Auswahlhandler in der gleichen App.

Selbst wenn Sie ein anderes Framework auswählen, beenden Sie a) die Verwendung von Webapp in bestimmten Fällen oder b) müssen Ihre Versionen für bestimmte SDK-Handler oder -Funktionen erstellen und verwalten, wenn Sie diese verwenden.

Ich bevorzuge Werkzeug gegenüber WebOb, aber nach über einem Jahr Portierung und Wartung von Versionen der SDK-Handler, die nativ mit tipfy arbeiten, wurde mir klar, dass dies eine verlorene Sache ist - um GAE langfristig zu unterstützen, ist es am besten, in der Nähe zu bleiben webapp / WebOb. Dies macht die Unterstützung für SDK-Bibliotheken zum Kinderspiel, die Wartung wird viel einfacher, es ist zukunftssicherer, da neue Bibliotheken und SDK-Funktionen sofort einsatzbereit sind und eine große Community die gleichen App Engine-Tools verwendet.

Eine spezifische webapp2-Verteidigung ist hier zusammengefasst . Hinzu kommt, dass webapp2 außerhalb von App Engine verwendet werden kann und einfach so angepasst werden kann, dass es wie beliebte Micro-Frameworks aussieht, und Sie haben eine Reihe überzeugender Gründe dafür. Außerdem hat webapp2 eine große Chance, in eine zukünftige SDK-Version aufgenommen zu werden (dies ist außeroffiziell, zitiere mich nicht :-), was es vorantreiben und neue Entwickler und Beiträge bringen wird.

Trotzdem bin ich ein großer Fan von Werkzeug und den Pocoo-Leuten und habe viel von Flask und anderen (web.py, Tornado) geliehen, aber - und Sie wissen, ich bin voreingenommen - die oben genannten Vorteile von webapp2 sollten berücksichtigt werden.

Ihre Frage ist äußerst weit gefasst, aber es scheint keine großen Probleme bei der Verwendung von Flask in Google App Engine zu geben.

Dieser Mailinglisten-Thread enthält Links zu mehreren Vorlagen:

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

Und hier ist ein Tutorial speziell für die Flask / App Engine-Kombination:

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

Siehe auch App Engine - Schwierigkeiten beim Zugriff auf Twitter-Daten - Flask , Flashen von Flask-Nachrichten schlägt bei Weiterleitungen fehl und Wie verwalte ich Python-Bibliotheken von Drittanbietern mit Google App Engine? (virtualenv? pip?) für Probleme mit Flask und Google App Engine.

Für mich war die Entscheidung für webapp2 einfach, als ich entdeckte, dass flask (von Anfang an) kein objektorientiertes Framework ist, während webapp2 ein rein objektorientiertes Framework ist. webapp2 verwendet das methodenbasierte Dispatching als Standard für alle RequestHandler (wie die Flask-Dokumentation es nennt und seit V0.7 in MethodViews implementiert). Während MethodViews in der Flasche ein Add-On sind, ist es ein zentrales Designprinzip für webapp2. So sieht Ihr Software-Design mit beiden Frameworks anders aus. Beide Frameworks verwenden heutzutage Jinja2-Vorlagen und sind ziemlich identisch.

Ich ziehe es vor, einem RequestHandler der Basisklasse Sicherheitsüberprüfungen hinzuzufügen und von diesem zu erben. Dies ist auch gut für Dienstprogrammfunktionen usw. Wie Sie beispielsweise in Link [3] sehen können, können Sie Methoden überschreiben, um das Versenden einer Anforderung zu verhindern.

Wenn Sie eine OO-Person sind oder einen REST-Server entwerfen müssen, würde ich webapp2 für Sie empfehlen. Wenn Sie einfache Funktionen mit Dekoratoren als Handler für mehrere Anforderungstypen bevorzugen oder sich mit der OO-Vererbung nicht wohl fühlen, wählen Sie flask. Ich denke, beide Frameworks vermeiden die Komplexität und Abhängigkeiten von viel größeren Frameworks wie Pyramiden.

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

Ich denke, Google App Engine unterstützt offiziell Flask Framework. Hier finden Sie einen Beispielcode und ein Tutorial -> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855

Ich habe webapp2 nicht ausprobiert und festgestellt, dass tipfy etwas schwierig zu verwenden ist, da Setup-Skripte und Builds erforderlich sind, mit denen Ihre Python-Installation anders als standardmäßig konfiguriert wird. Aus diesen und anderen Gründen habe ich mein größtes Projekt nicht von einem Framework abhängig gemacht. Stattdessen verwende ich die einfache Webanwendung. Fügen Sie die Bibliothek mit dem Namen "Becher" hinzu, um Sitzungsfunktionen zu erhalten. Django verfügt bereits über integrierte Übersetzungen für Wörter, die vielen Anwendungsfällen gemeinsam sind Die lokalisierte Anwendung Django war die richtige Wahl für mein größtes Projekt. Die beiden anderen Frameworks, die ich tatsächlich mit Projekten in einer Produktionsumgebung bereitgestellt habe, waren GAEframework.com und web2py. Im Allgemeinen scheint das Hinzufügen eines Frameworks, das die Template-Engine ändert, zu Inkompatibilitäten zwischen alten und neuen Versionen zu führen.

Ich habe die Erfahrung gemacht, dass ich meinen Projekten nur ungern ein Framework hinzufügen möchte, es sei denn, sie lösen die fortgeschritteneren Anwendungsfälle (Datei-Upload, Multi-Auth, Admin-UI sind drei Beispiele für fortgeschrittenere Anwendungsfälle, für die es derzeit kein Framework für Gae gibt handhabt sich gut.