问题：Flask vs webapp2（适用于Google App Engine）
我正在启动新的Google App Engine应用程序，目前正在考虑两个框架：Flask和webapp2。我对以前的App Engine应用程序使用的内置webapp框架感到非常满意，因此我认为webapp2会更好，并且不会有任何问题。
但是，Flask有很多不错的评论，我真的很喜欢Flask的方法以及到目前为止我在文档中已经读过的所有东西，我想尝试一下。但是我有点担心Flask会遇到的局限性。
因此，问题是- 您是否知道Flask可能会带入Google App Engine应用程序的任何问题，性能问题，限制（例如，路由系统，内置授权机制等）？“问题”是指我无法在几行代码（或任何合理数量的代码和工作量）中解决的问题，或者是完全不可能的事情。
还有一个后续问题：尽管我可能会遇到任何问题，但您认为Flask中是否有任何杀手级功能可以打动我，让我使用它？
回答 0
免责声明：我是tipfy和webapp2的作者。
坚持使用webapp（或其自然发展版本，webapp2）的一大优势是，您不必为自己选择的框架为现有的SDK处理程序创建自己的版本。
例如，deferred使用一个webapp处理程序。要在纯Flask视图中使用werkzeug.Request和werkzeug.Response来使用它，您需要为此实现deferred（就像我在这里为tipfy 所做的那样）。
其他处理程序也会发生同样的情况：blobstore（Werkzeug仍然不支持范围请求，因此即使您创建了自己的处理程序，也需要使用WebOb －请参见tipfy.appengine.blobstore），邮件，XMPP等，或以后包含在SDK中的其他内容。
对于使用App Engine创建的库，也是如此，例如ProtoRPC，它基于webapp，并且如果您不想混合使用webapp和框架，则需要端口或适配器才能与其他框架一起使用。同一应用中的选择处理程序。
因此，即使您选择其他框架，您也将不得不结束a）在某些特殊情况下使用webapp或b）必须创建和维护特定SDK处理程序或功能的版本（如果要使用它们）。
与WebOb相比，我更偏爱Werkzeug，但是在移植和维护可与Tipfy一起使用的SDK处理程序版本超过一年之后，我意识到这是一个失败的原因-长期支持GAE，最好是保持与webapp / WebOb。它使对SDK库的支持变得轻而易举，维护变得更加容易，因为新的库和SDK功能将立即可用，因此它具有更强的前瞻性，并且大型社区可以使用相同的App Engine工具来受益。
这里总结了一个特定的webapp2防御。此外，webapp2可以在App Engine之外使用，并且易于自定义以使其看起来像流行的微框架，并且您有很多吸引人的理由。而且，webapp2有很大的机会被包含在将来的SDK版本中（这是非正式的，不要引用我的：-），这将推动它向前发展并带来新的开发人员和贡献。
也就是说，我是Werkzeug和Pocoo的忠实拥护者，并向Flask和其他人（web.py，Tornado）借了很多钱，但是-我知道，我有偏见-以上webapp2的好处应该被考虑在内。
回答 1
您的问题非常广泛，但是在Google App Engine上使用Flask似乎没有大问题。
该邮件列表线程链接到多个模板：
以下是针对Flask / App Engine组合的教程：
http://www.franciscosouza.com/2010/08/flying-with-flask-on-google-app-engine/
另请参阅App Engine-难以访问Twitter数据-Flask，Flask消息刷新无法跨重定向重定向，以及如何使用Google App Engine管理第三方Python库？（virtualenv？pip？）解决人们对于Flask和Google App Engine的问题。
回答 2
对我来说，当我发现烧瓶不是（从一开始就）不是面向对象的框架，而webapp2是一个纯粹的面向对象的框架时，对webapp2的决定很容易。webapp2将基于方法的调度作为所有RequestHandler的标准使用（如烧瓶文档在MethodViews中从V0.7开始对其进行调用和实现）。在烧瓶中，MethodViews是附加组件，它是webapp2的核心设计原则。因此，使用这两种框架，您的软件设计将看起来有所不同。如今，这两个框架都使用jinja2模板，并且功能完全相同。
我更喜欢将安全检查添加到基类RequestHandler并从中继承。这对于实用程序功能等也很有用。例如，您可以在链接[3]中看到，您可以重写方法以防止调度请求。
如果您是面向对象的人，或者需要设计REST服务器，我将为您推荐webapp2。如果您希望使用带有装饰器的简单函数作为多种请求类型的处理程序，或者对OO继承不满意，请选择flask。我认为这两个框架都避免了金字塔等大型框架的复杂性和依赖性。
回答 3
我认为Google App Engine正式支持Flask框架。这里有一个示例代码和教程-> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855
回答 4
我没有尝试使用webapp2，但发现tipfy有点难以使用，因为它需要安装脚本和用于将python安装配置为默认设置以外的构建。由于这些原因和其他原因，我没有使我最大的项目依赖于框架，而是使用普通的webapp，而是添加了名为beaker的库以获取会话功能，并且django已经内置了许多用例通用词的翻译，因此在构建框架时本地化的应用程序django是我最大的项目的正确选择。我实际在项目中部署到生产环境的其他两个框架分别是GAEframework.com和web2py，通常看来，添加一个更改其模板引擎的框架可能会导致新旧版本不兼容。
因此，我的经验是，除非他们解决了更高级的用例（文件上传，多重身份验证，管理ui是目前尚无框架的3个更高级的用例示例），否则我不愿意在项目中添加框架处理得很好。