我正在启动新的GoogleAppEngine应用程序，目前正在考虑两个框架：Flask和webapp2。我对我以前的应用程序引擎应用程序使用的内置webapp框架相当满意，因此我认为webapp2会更好，而且不会有任何问题
然而，有很多关于Flask的好评论，我真的很喜欢它的方法和我在文档中读到的所有东西，我想尝试一下。但我有点担心我可以用烧瓶来面对未来的限制
所以，问题是-你知道Flask会给Google App Engine应用程序带来什么问题、性能问题、限制（例如路由系统、内置授权机制等）？所谓“问题”是指我无法在几行代码（或任何合理数量的代码和努力）中解决的问题或者是完全不可能的事情
作为一个后续问题：烧瓶里有没有什么杀手级的功能，你认为可以让我大吃一惊，让我使用它，尽管我可能会面临任何问题
回答的
免责声明：我是tipfy和webapp2的作者
坚持使用webapp（或其自然演变，webapp2）的一大优势是，您不必为您选择的框架的现有SDK处理程序创建自己的版本
例如，deferred使用webapp处理程序。要在纯烧瓶视图中使用它，使用werkzeug.Request和werkzeug.Response，您需要为它实现延迟（就像我在这里为tipfy做的那样）
其他处理程序也是如此：blobstore（Werkzeug仍然不支持范围请求，因此即使创建自己的处理程序，也需要使用WebOb——请参见tipfy.appengine.blobstore）、mail、XMPP等，或者将来SDK中包含的其他处理程序
如果你不想在同一个应用程序中混合使用webapp和你选择的框架处理程序，同样的情况也会发生在使用appengine创建的库上，比如ProtoRPC，它基于webapp，需要一个端口或适配器来与其他框架一起工作
因此，即使您选择了不同的框架，您也将结束a）在某些特殊情况下使用webapp，或b）必须为特定SDK处理程序或功能创建和维护您的版本（如果您要使用它们）
我更喜欢Werkzeug而不是WebOb，但在移植和维护与tipfy本机协同工作的SDK处理程序版本一年多之后，我意识到这是一个失败的原因——为了长期支持GAE，最好是与webapp/WebOb保持密切联系。它使对SDK库的支持变得轻而易举，维护变得容易得多，因为新的库和SDK功能将开箱即用，并且有一个大型社区围绕相同的应用程序引擎工具工作的好处，因此更适合未来
这里总结了一个具体的webapp2防御。此外，webapp2还可以在appengine之外使用，并且易于定制，使其看起来像流行的微框架，您有很多令人信服的理由去使用它。此外，webapp2有很大的机会被纳入未来的SDK版本中（这是额外的官方版本，请不要引用我的话：-），这将推动它向前发展，并带来新的开发人员和贡献
也就是说，我是Werkzeug和Pocoo的忠实粉丝，从Flask和其他人那里借了很多东西（web.py，Tornado），但是——而且，你知道，我有偏见——应该考虑上述webapp2的好处