[解決済み] Google App EngineのためのFlaskとwebapp2の比較

質問

Google App Engineのアプリケーションを新規に立ち上げるのですが、現在2つのフレームワークを検討しています。 フラスコ と webapp2 . 以前のApp Engineアプリケーションで使用したビルトインwebappフレームワークにはむしろ満足しているので、webapp2はさらに良くなると思うし、問題はないだろうと思っています。

しかし、Flaskについては良い評価が多く、そのアプローチやこれまでのドキュメントを読んだ限りでは本当に気に入っており、試してみたいと思っています。しかし、私はFlaskの先々で直面する可能性のある制限について少し心配しています。

そこで質問なのですが Flask が Google App Engine アプリケーションにもたらす可能性のある問題、パフォーマンスの問題、制限（ルーティングシステム、組み込みの認証メカニズムなど）をご存知ですか？ 問題"問題は、私が数行のコード（または任意の合理的な量のコードと努力）で回避できないもの、または完全に不可能であるものを意味します。

そしてフォローアップの質問ですが、Flaskのキラー機能で、私の心を打ち、私が直面しうるどんな問題にもかかわらずそれを使わせることができると思うものはありますか？

どのように解決するのですか？

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

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

たとえば 遅延 は webapp ハンドラを使っています。これを純粋な Flask ビューで werkzeug.Request と werkzeug.Response を使って使うには、これに対して deferred を実装する必要があります (私がやったように ここで をtipfy用にしたように)。

他のハンドラについても同じことが言えます: blobstore (Werkzeug はまだレンジリクエストをサポートしていないので、独自のハンドラを作成する場合でも WebOb を使用する必要があります -- こちらを参照してください)。 を参照してください。 を参照)、メール、XMPP など、または将来 SDK に含まれるその他のものを使用する必要があります。

また、App Engine を念頭に置いて作成された、次のようなライブラリについても同様です。 ProtoRPC のように、App Engineを考慮して作成されたライブラリも同様です。これはwebappをベースにしており、webappと選択したフレームワークのハンドラを同じアプリで混在させたくない場合は、他のフレームワークで動作させるためのポートまたはアダプタが必要になります。

したがって、たとえ別のフレームワークを選択したとしても、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の利点は考慮されるべきものです。