我正在启动新的Google App Engine应用程序，目前正在考虑两个框架：Flask和webapp2。我对我以前的App Engine应用程序使用的内置webapp框架非常满意，所以我认为webapp2会更好，我也不会有任何问题。
然而，有很多关于Flask的好评，我真的很喜欢它的方法以及我在文档中到目前为止所阅读的所有内容，我想尝试一下。但我有点担心我可以面对Flask的限制。
所以，问题是 - 你知道Flask可以带入Google App Engine应用程序的任何问题，性能问题，限制（例如路由系统，内置授权机制等）吗？ “问题”是指我无法通过几行代码（或任何合理数量的代码和工作）或者完全不可能的东西来解决的问题。
作为一个后续问题：你认为Flask中是否有任何杀手功能可以让我大吃一惊并让我使用它，尽管我可以面对任何问题？
答案 0 :(得分：138)
免责声明：我是tipfy和webapp2的作者。
坚持使用webapp（或其自然发展，webapp2）的一大优势是，您不必为您选择的框架为现有的SDK处理程序创建自己的版本。
例如，deferred使用webapp处理程序。要在纯Flask视图中使用它，使用werkzeug.Request和werkzeug.Response，你需要为它实现延迟（就像我为了tipfy做here）。
其他处理程序也是如此：blobstore（Werkzeug仍然不支持范围请求，因此即使您创建自己的处理程序，您也需要使用WebOb - 请参阅tipfy.appengine.blobstore），mail，XMPP和等等，或将来包含在SDK中的其他内容。
对于使用App Engine创建的库也是如此，例如基于webapp的ProtoRPC，如果你不想混合webapp，则需要一个端口或适配器来与其他框架一起工作和同一个应用程序中的你的框架选择处理程序。
因此，即使你选择了不同的框架，你也会结束a）在某些特殊情况下使用webapp或者b）必须为特定的SDK处理程序或功能创建和维护你的版本，如果你使用它们的话。 / p>
我更喜欢Werkzeug而不是WebOb，但是经过一年多的移植和维护版本的SDK处理程序本身就是tipfy工作，我意识到这是一个失败的原因 - 从长远来看支持GAE，最好的是保持接近webapp / WebOb。它使得SDK库的支持变得轻而易举，维护变得更加容易，它更具有前瞻性，因为新的库和SDK功能将开箱即用，并且大型社区可以利用相同的App Engine工具。< / p>
总结了here的特定webapp2防御。添加到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的好处。
答案 1 :(得分：13)
您的问题非常广泛，但在Google App Engine上使用Flask似乎没有什么大问题。
此邮件列表线程链接到多个模板：
这是一个特定于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所遇到的问题。
答案 2 :(得分：3)
对我来说，当我发现烧瓶不是面向对象的框架（从头开始）时，webapp2的决定很容易，而webapp2是一个纯粹的面向对象的框架。 webapp2使用基于方法的调度作为所有RequestHandler的标准（烧瓶文档调用它并在MethodViews中自V0.7起实现它）。在烧瓶中，MethodViews是一个附加组件，它是webapp2的核心设计原则。因此，使用这两个框架，您的软件设计会有所不同。这两个框架都使用现在的jinja2模板，并且功能相同。
我更喜欢将安全检查添加到基类RequestHandler并从中继承。这也适用于实用程序功能等。例如，您可以在链接[3]中看到，可以覆盖防止调度请求的方法。
如果您是OO人员，或者您需要设计REST服务器，我会为您推荐webapp2。如果您更喜欢使用装饰器作为多个请求类型的处理程序的简单函数，或者您对OO继承感到不舒服，那么请选择flask。我认为这两个框架都避免了金字塔等更大框架的复杂性和依赖性。
答案 3 :(得分：2)
我没有尝试使用webapp2，发现tipfy有点难以使用，因为它需要安装脚本和构建，将python安装配置为默认值以外的版本。由于这些和其他原因，我没有让我最大的项目依赖于框架而我使用普通的webapp，添加名为beaker的库以获得会话功能，而django已经内置了许多用例常用的单词的翻译，因此在构建时本地化应用程序django是我最大项目的正确选择。我实际部署到生产环境项目的其他两个框架是GAEframework.com和web2py，通常看起来添加一个更改其模板引擎的框架可能会导致新旧版本之间不兼容。
所以我的经验是，我不愿意为我的项目添加一个框架，除非他们解决了更高级的用例（文件上传，多个auth，管理员ui是3个更高级用例的例子，没有框架的gae目前处理得很好。
答案 4 :(得分：2)
我认为谷歌应用引擎正式支持烧瓶框架。这里有一个示例代码和教程 - ＆gt; https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855