Flask vs Google App Engineのwebapp2
新しいGoogle App Engineアプリケーションを開始し、現在2つのフレームワーク Flask と webapp2 を検討しています。以前のApp Engineアプリケーションで使用していた組み込みのwebappフレームワークにかなり満足しているので、webapp2の方がさらに良くなり、問題はないと思います。
ただし、Flaskには多くの優れたレビューがあります。そのアプローチと、これまでにドキュメントで読んだことすべてが大好きで、試してみたいと思います。しかし、Flaskで将来直面する可能性がある制限について少し心配しています。
したがって、質問は-問題、パフォーマンスの問題、制限（ルーティングシステム、組み込みの認証メカニズムなど）を知っていますか？Flask 「問題」とは、数行のコード（または妥当な量のコードと労力）で回避できないもの、または完全に不可能です。
そして、フォローアップの質問として：Flaskにキラー機能はありますか？
免責事項：私はtipfyとwebapp2の著者です。
Webapp（またはその自然な進化、webapp2）に固執する大きな利点は、選択したフレームワークの既存のSDKハンドラー用に独自のバージョンを作成する必要がないことです。
たとえば、 deferred はwebappハンドラーを使用します。 werkzeug.Requestとwerkzeug.Responseを使用して、純粋なFlaskビューで使用するには、deferredを実装する必要があります（私が here tipfyのように） ）。
同じことが他のハンドラーでも発生します：blobstore（Werkzeugはまだ範囲要求をサポートしていないため、独自のハンドラーを作成する場合でもWebObを使用する必要があります- tipfy.appengine.blobstore を参照）、メール、XMPPなど、または将来SDKに含まれるその他のもの。
ProtoRPC のようなApp Engineで作成されたライブラリでも同じことが起こります。これは、webappに基づいており、webappを混在させたくない場合、他のフレームワークと連携するためにポートまたはアダプターが必要になります同じアプリのフレームワーク選択ハンドラー。
そのため、別のフレームワークを選択した場合でも、a）特別な場合にwebappを使用するか、b）特定のSDKハンドラーまたは機能を使用する場合は、バージョンを作成および維持する必要があります。
WebObよりもWerkzeugの方が好きですが、tipfyでネイティブに動作するバージョンのSDKハンドラーの移植と保守を1年以上行った後、これが失われた原因であることに気付きました-長期にわたってGAEをサポートするには、 webapp/WebOb。 SDKライブラリのサポートが簡単になり、メンテナンスがはるかに簡単になります。新しいライブラリとSDK機能がそのまま使用できるので、より将来性があり、同じApp Engineツールを使用して作業する大規模なコミュニティの利点があります。
特定のwebapp2防御が要約されます here 。 webapp2はApp Engineの外部で使用可能 であり、 一般的なマイクロフレームワークのようにカスタマイズしやすい に加えて、説得力のある一連の理由があるそれのための。また、webapp2は将来のSDKリリースに含まれる大きなチャンスがあります（これは非公式です、私を引用しないでください:-)それは前進し、新しい開発者と貢献をもたらします。
とはいえ、私はWerkzeugとPocooの大ファンであり、Flaskおよびその他（web.py、Tornado）から多くを借りましたが、私は知っています。 m偏り-上記のwebapp2の利点を考慮する必要があります。
あなたの質問は非常に広範ですが、Google App EngineでFlaskを使用しても大きな問題はないようです。
このメーリングリストのスレッドは、いくつかのテンプレートにリンクしています。
そして、Flask/App Engineの組み合わせに固有のチュートリアル：
http://www.franciscosouza.com/2010/08/flying-with-flask-on-google-app-engine/
また、 App Engine-Twitterデータへのアクセスの難しさ-Flask 、 リダイレクト全体でフラスコメッセージのフラッシュが失敗する 、および サードパーティの管理方法Python Google App Engineのライブラリ？（virtualenv？pip？） FlaskおよびGoogle App Engineで発生した問題の場合）.
私にとってwebapp2の決定は、flaskはオブジェクト指向フレームワークではありませんが（最初から）、webapp2は純粋なオブジェクト指向フレームワークです。webapp2はMethod Based Dispatchingを次のように使用します。すべてのRequestHandlersの標準です（flaskドキュメントがMethodViewsのV0.7から呼び出して実装します）。flask MethodViewsはアドオンであるため、 webapp2の中核となる設計原則であるため、両方のフレームワークを使用すると、ソフトウェア設計が異なって見えます。
基本クラスのRequestHandlerにセキュリティチェックを追加し、それを継承することを好みます。これはユーティリティ関数などにも適しています。たとえば、リンク[3]でわかるように、メソッドをオーバーライドしてリクエストのディスパッチを防ぐことができます。
あなたがオブジェクト指向の人である場合、またはRESTサーバーを設計する必要がある場合は、webapp2をお勧めします。複数の要求タイプのハンドラーとしてデコレーターを使用した単純な機能を好む場合、またはオブジェクト指向継承に不安がある場合は、flaskを選択してください。どちらのフレームワークも、ピラミッドのようなはるかに大きなフレームワークの複雑さと依存関係を回避すると思います。
私はwebapp2を試しませんでしたが、tipfyは、pythonインストールをデフォルト以外に設定するセットアップスクリプトとビルドを必要とするため、使用が少し難しいことがわかりました。私の最大のプロジェクトをフレームワークに依存させ、代わりにプレーンwebappを使用し、ビーカーと呼ばれるライブラリを追加してセッション機能を取得し、Djangoはすでに多くのユースケースに共通する単語の組み込み翻訳を持っているため、ローカライズされたアプリケーションDjangoは私の最大のプロジェクトにとって正しい選択でした。実際にプロジェクトとともに実稼働環境にデプロイした他の2つのフレームワークはGAEframework.comとweb2pyでした。テンプレートエンジンを変更すると、古いバージョンと新しいバージョンの間に互換性がなくなる可能性があります。
私の経験では、より高度なユースケースを解決しない限り、プロジェクトにフレームワークを追加することに消極的です（ファイルアップロード、マルチ認証、管理UIは、現時点ではGAE用のフレームワークではないより高度なユースケースの3つの例です）うまく処理します。
Google App Engineは公式にflaskフレームワークをサポートしています。ここにサンプルコードとチュートリアルがあります-> https://console.developers.google.com/start/appengine?_ga = 1.36257892.596387946.1427891855