我正在启动新的Google App Engine应用程序，目前正在考虑两个框架：Flask和webapp2。我对我以前的App Engine应用程序使用的内置webapp框架非常满意，所以我认为webapp2会更好，我也不会遇到任何问题。Google App Engine的Flask vs webapp2
但是，Flask有很多很好的评论，我非常喜欢它的方法以及迄今为止在文档中已经阅读过的所有内容，我想尝试一下。但我有点担心我可以用Flask面对这些局限性。
因此，问题是 - 您是否知道Flask可能带入Google App Engine应用程序的任何问题，性能问题，限制（例如路由系统，内置授权机制等）？“问题”我的意思是我不能在几行代码（或任何合理数量的代码和努力）中解决某些问题，或者完全不可能。
作为一个后续问题：Flask中是否存在任何杀手特性，您认为尽管我可以面对任何问题，但是我认为这些特性可能会让我大开眼界并使用它。
声明：我是tipfy和webapp2的作者。
坚持使用webapp（或其自然进化，webapp2）的一大优势是您无需为您选择的框架为现有SDK处理程序创建自己的版本。例如，deferred使用webapp处理程序。要在纯Flask视图中使用它，使用werkzeug.Request和werkzeug.Response，您需要实现延迟（就像我为tipfy做的here）。
对于其他处理程序也是如此：blobstore（Werkzeug仍不支持范围请求，所以即使您创建自己的处理程序，请参阅tipfy.appengine.blobstore），邮件，XMPP等，或将来包含在SDK中的其他人。
对于使用App Engine创建的库也会发生同样的情况，例如ProtoRPC，它基于webapp，如果您不想将webapp和您的应用程序混合使用，并且需要端口或适配器来与其他框架一起工作，在同一个应用程序中的选择框架处理程序。
因此，即使您选择了不同的框架，您也会在某些特殊情况下使用webapp结束a）或者必须为特定的SDK处理程序或功能创建和维护您的版本（如果要使用它们）。
我更喜欢Werkzeug而不是WebOb，但经过一年多的移植和维护版本的SDK处理程序本身与tipfy一起工作，我意识到这是一个失败的原因 - 从长远来看，支持GAE，最好的以保持接近webapp/WebOb。它使得SDK库的支持变得轻而易举，维护变得更加容易，因为新的库和SDK功能可以即装即用，而且围绕相同App Engine工具的大型社区的优势也更加明显。
一个特定的webapp2防御摘要here。添加到那些webapp2 can be used outside of App Engine和easy to be customized to look like popular micro-frameworks，你有一个很好的理由去为它。此外，webapp2很有可能被纳入未来的SDK版本（这是非官方的，不要引用我:-)，这将推动它，并带来新的开发人员和贡献。
这就是说，我是Werkzeug和Pocoo家伙的忠实粉丝，他们从Flask和其他人（web.py，Tornado）借了很多，但是 - 而且，你知道，我有偏见 - 应该考虑到以上webapp2的好处。
谢谢，@moraes！足够坚固。我认为诸如blobstore，邮件（可能是ProtoRPC）对于该项目来说非常重要，我希望尽可能顺利地与他们合作。另外，我认为如果您可以轻松避免，混合不同的框架并不是最好的想法。而且，尽管我很同情Flask，但我对webapp2印象非常深刻，并且我的双手痒痒地想要尝试一下。谢谢你的回答和webapp2！ –
@moraes可以使用Apache运行webapp2吗？任何链接？ – 18bytes
@Sundar它可以在任何WSGI兼容的Web服务器上运行。对于Apache，有http://code.google.com/p/modwsgi/和其他人。 – moraes
您的问题非常广泛，但在Google App Engine上使用Flask似乎没有大问题。
这个邮件列表线程链接到几个模板：
这里是具体到瓶/ App Engine的组合教程：
http://www.franciscosouza.com/2010/08/flying-with-flask-on-google-app-engine/
而且，看App Engine - Difficulty Accessing Twitter Data - Flask， Flask message flashing fails across redirects和How do I manage third-party Python libraries with Google App Engine? (virtualenv? pip?)针对人们在Flask和Google App Engine中遇到的问题。
谢谢，@agf。我以前看过这篇文章的大部分内容，但我觉得我对个人体验更感兴趣。我不认为这个问题太广泛了，因为我对全面的讨论或有关问题的详细信息不感兴趣，只要指出这一点，这将很难或不可能实现。 –
@Anton，要求主观的个人经验非常接近SO [不问问题]的指导原则（http://stackoverflow.com/faq#dontask）。 – James
@詹姆斯 - 不同意。我不会问你猜测，假设或主观感受。我询问你的经验，即关于你自信知道的*事实*。没有过时的帖子，也没有其他人在重度定制时遇到的问题，只是事实。不同意 - 好的，只需标记它。 –
我没有尝试webapp2，发现tipfy有点难以使用，因为它需要安装脚本和编译配置你的python安装到非默认状态。由于这些原因以及其他原因，我没有做出我最大的项目依赖于框架，我使用简单的webapp来代替，添加名为beaker的库以获得会话能力，并且django已经具有用于许多用例共有的单词的内置翻译，所以当构建本地化的应用django是我最大的项目的正确选择。我实际将项目部署到生产环境的其他两个框架是GAEframework.com和web2py，通常看起来添加一个更改其模板引擎的框架可能会导致旧版本和新版本之间不兼容。
所以我的经验是，我不愿意为我的项目添加一个框架，除非他们解决了更高级的用例（文件上传，多重认证，管理员用户界面是更高级用例的3个示例，没有框架GAE的时刻处理好
我认为谷歌应用程序引擎正式支持烧瓶框架有一个示例代码和教程这里 - >https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855
对我来说，这不是官方的支持，这只是一个例子，“你也可以用Flask做”。对于webapp2，仍然有详细的手册，其中添加了GAE特定的项目。 – silpol
对我来说webapp2的决定是容易的，当我发现烧瓶不是一个面向对象的框架（从一开始），而webapp2是一个纯粹的面向对象的框架。webapp2使用基于方法调度作为所有RequestH的标准（如flask文档调用它并从MethodViews中的V0.7开始实现它）。在烧瓶中MethodViews是一个附加组件，它是webapp2的核心设计原则。因此，使用这两种框架，您的软件设计看起来会不同。这两个框架使用现今的jinja2模板，功能完全相同。
我宁愿将安全检查添加到基类RequestHandler并从中继承。这对于实用程序函数等也很有用。正如您可以在链接[3]中看到的那样，您可以覆盖方法来阻止调度请求。
如果您是面向对象的人，或者您需要设计REST服务器，我会为您推荐webapp2。如果你喜欢装饰器的简单函数作为多个请求类型的处理器，或者你对OO继承感到不舒服，那么选择flask。我认为这两个框架都可以避免像金字塔这样的大型框架的复杂性和依赖性。
就是这样，OOP支持赢得了我。我原本使用web.py，但webapp2似乎有没有解决方法，我做了web.py上的整洁结构。烧瓶可能很容易启动，但如果您打算制作更大的应用程序，则需要更多的工作 –
我不知道很多关于webapp2的，但我一直在使用瓶几个月，我喜欢它。我发现了真正帮助我的瓶子插件，例如支持多种语言的“flask-babel”，以及用于CSRF支持的“flask-seasurf”来保护我的表格。 – ThePloki