Google App EngineのFlaskとwebapp2

新しいGoogle App Engineアプリケーションを開始し、現在、Flaskとwebapp2の 2つのフレームワークを検討しています。以前のApp Engineアプリケーションで使用した組み込みのwebappフレームワークにかなり満足しているので、webapp2の方がさらに優れており、問題は発生しないと思います。

しかし、Flaskの良いレビューはたくさんあります。私は、Flaskのアプローチと、ドキュメントでこれまでに読んだすべてのものを本当に気に入っています。ぜひ試してみたいと思います。しかし、私はFlaskを使用して将来直面する可能性のある制限について少し心配しています。

したがって、問題は、FlaskがGoogle App Engineアプリケーションにもたらす可能性のある問題、パフォーマンスの問題、制限（ルーティングシステム、組み込みの承認メカニズムなど）を知っていますか？「問題」とは、数行のコード（または妥当な量のコードと作業）で回避できないこと、または完全に不可能であることを意味します。

そしてフォローアップの質問として：私が直面する可能性のある問題にもかかわらず、Flaskに私の心を吹き飛ばして私にそれを使用させることができるキラー機能はありますか？

免責事項：私はtipfyとwebapp2の作者です。

webapp（またはその自然な進化、webapp2）を使用する大きな利点は、選択したフレームワークの既存のSDKハンドラー用に独自のバージョンを作成する必要がないことです。

たとえば、deferredはwebappハンドラーを使用します。それをwerkzeug.Requestとwerkzeug.Responseを使用して純粋なFlaskビューで使用するには、そのために据え置きを実装する必要があります（tipfyのためにここで行ったように）。

-ブロブストア（参照あなたがあなた自身のハンドラを作成する場合でも、WebObに関するを使用する必要がありますので、WERKZEUGはまだ、範囲要求をサポートしていません：同じことが他のハンドラのために起こるtipfy.appengine.blobstoreを、メール、XMPPなど、）または将来SDKに含まれるもの。

また、App Engineを使用して作成されたライブラリ（ProtoRPCなど）でも同じことが起こります。これは、webappに基づいており、webappとyour-framework-of-を混在させたくない場合は、他のフレームワークと連携するためにポートまたはアダプターが必要になります。同じアプリ内の選択ハンドラ。

したがって、別のフレームワークを選択した場合でも、a）特別な場合にwebappを使用するか、b）特定のSDKハンドラーまたは機能のバージョンを作成して維持する必要があります（使用する場合）。

私はWebObよりもWerkzeugを非常に好みますが、tipfyでネイティブに動作するSDKハンドラーのバージョンを1年以上移植して維持した後、これが失われた原因であることに気付きました-長期にわたってGAEをサポートするには、近くにとどまることが最善ですwebapp / WebOb。これにより、SDKライブラリのサポートが簡単になり、メンテナンスが非常に簡単になり、新しいライブラリとSDK機能がそのまま動作し、同じApp Engineツールを取り巻く大規模なコミュニティのメリットがあるため、将来性が高まります。

特定のwebapp2防御をここにまとめます。これらに加えて、webapp2はApp Engineの外部で使用でき、人気のあるマイクロフレームワークのようにカスタマイズするのが簡単であり、それには説得力のある理由がいくつかあります。また、webapp2は将来のSDKリリースに含まれる大きなチャンスがあります（これは公式ではありませんが、私を引用しないでください:-)。これにより、それが推進され、新しい開発者と貢献がもたらされます。

とは言っても、私はWerkzeugとPocooの連中の大ファンであり、Flaskやその他（web.py、Tornado）から多くを借りましたが、-そして、ご存知のように-上記のwebapp2の利点は考慮されます。

あなたの質問は非常に広範ですが、Google App EngineでFlaskを使用しても大きな問題はないようです。

このメーリングリストのスレッドは、いくつかのテンプレートにリンクしています。

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

そして、ここにFlask / App Engineの組み合わせに固有のチュートリアルがあります：

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

また、参照の難しさへのアクセスTwitterのデータ- - App Engineのフラスコを、フラスコメッセージの点滅がリダイレクト全体に失敗し、そしてどのように私はGoogle App Engineを持つサードパーティのPythonライブラリを管理していますか？（virtualenv？pip？） FlaskとGoogle App Engineで発生した問題について。

私にとって、フラスコがオブジェクト指向のフレームワークではない（最初から）のではなく、webapp2が純粋なオブジェクト指向のフレームワークであることがわかったとき、webapp2の決定は簡単でした。webapp2は、すべてのRequestHandlerの標準としてメソッドベースのディスパッチを使用します（フラスコのドキュメントがそれを呼び出し、MethodViewsのV0.7以降で実装しているため）。フラスコでは、MethodViewsはアドオンですが、webapp2の中心的な設計原則です。したがって、両方のフレームワークを使用すると、ソフトウェアのデザインは異なって見えます。どちらのフレームワークも現在のjinja2テンプレートを使用しており、機能はほぼ同じです。

私は基本クラスのRequestHandlerにセキュリティチェックを追加し、それから継承することを好みます。これはユーティリティ関数などにも適しています。たとえばリンク[3]でわかるように、メソッドをオーバーライドしてリクエストのディスパッチを防ぐことができます。

オブジェクト指向の人、またはRESTサーバーを設計する必要がある場合は、webapp2をお勧めします。複数の要求タイプのハンドラーとしてデコレーターを使用する単純な関数を好む場合、またはOO継承に不快な場合は、フラスコを選択してください。どちらのフレームワークも、ピラミッドのようなはるかに大きなフレームワークの複雑さと依存関係を回避していると思います。

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

google app engineはフラスコのフレームワークを公式にサポートしていると思います。ここにサンプルコードとチュートリアルがあります-> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855

私はwebapp2を試してみませんでしたが、Pythonのインストールをデフォルト以外に設定するセットアップスクリプトとビルドが必要だったため、tipfyの使用は少し難しいことがわかりました。これらおよびその他の理由で、最大のプロジェクトをフレームワークに依存させず、代わりにプレーンWebアプリケーションを使用し、ビーカーと呼ばれるライブラリを追加してセッション機能を取得します。djangoには、多くのユースケースに共通する単語の組み込みの翻訳があるため、ローカライズされたアプリケーションdjangoは、私の最大のプロジェクトにとって正しい選択でした。プロジェクトで実際に本番環境にデプロイした他の2つのフレームワークは、GAEframework.comとweb2pyでした。一般に、テンプレートエンジンを変更するフレームワークを追加すると、古いバージョンと新しいバージョンの非互換性が生じる可能性があるようです。

したがって、私の経験では、プロジェクトにフレームワークを追加することに消極的です。ただし、プロジェクトがより高度なユースケースを解決しない限り（ファイルアップロード、マルチ認証、管理UIは、現時点でgaeのフレームワークがない3つの高度なユースケースの例です）うまく処理します。