Google App Engine 的 Flask 与 webapp2答案

【问题标题】：Flask vs webapp2 for Google App EngineGoogle App Engine 的 Flask 与 webapp2
【发布时间】：2011-10-10 02:28:20
【问题描述】：

我正在启动新的 Google App Engine 应用程序，目前正在考虑两个框架：Flask 和 webapp2。我对我以前的 App Engine 应用程序使用的内置 webapp 框架相当满意，所以我认为 webapp2 会更好，我不会有任何问题。

但是，有很多对 Flask 的好评，我真的很喜欢它的方法以及到目前为止我在文档中阅读的所有内容，我想尝试一下。但我有点担心我在使用 Flask 时可能面临的限制。

那么，问题是 - 您知道 Flask 可能给 Google App Engine 应用程序带来的任何问题、性能问题、限制（例如路由系统、内置授权机制等）吗？ “问题”是指我无法通过几行代码（或任何合理数量的代码和努力）解决的问题，或者完全不可能的问题。

作为一个后续问题：Flask 中是否有任何杀手级功能让我大吃一惊并让我使用它，尽管我可能会遇到任何问题？

【问题讨论】：

我对 webapp2 了解不多，但我已经使用 Flask 几个月了，我喜欢它。我找到了真正帮助我的烧瓶插件，例如 flask-babel 用于多语言支持，flask-seasurf 用于 CSRF 支持以保护我的表单。

标签： python google-app-engine flask webapp2

【解决方案1】：

我没有尝试 webapp2，发现tipfy 有点难以使用，因为它需要安装脚本和构建，将你的python 安装配置为默认值以外。由于这些和其他原因，我没有让我最大的项目依赖于框架，而是使用普通的 webapp，添加名为 beaker 的库以获得会话功能，并且 django 已经为许多用例常见的单词提供了内置翻译，所以在构建一个本地化应用程序 django 是我最大项目的正确选择。我实际将项目与项目一起部署到生产环境的另外两个框架是 GAEframework.com 和 web2py，通常似乎添加一个更改其模板引擎的框架可能会导致新旧版本之间的不兼容。

所以我的经验是，我不愿意在我的项目中添加框架，除非它们解决了更高级的用例（文件上传、多重身份验证、管理 ui 是没有 gae 框架的更高级用例的 3 个示例目前处理得很好。

【讨论】：

【解决方案2】：

免责声明：我是tipfy和webapp2的作者。

坚持使用 webapp（或其自然演变，webapp2）的一大优势是您不必为您选择的框架为现有 SDK 处理程序创建自己的版本。

例如，deferred 使用 webapp 处理程序。要在纯 Flask 视图中使用它，使用 werkzeug.Request 和 werkzeug.Response，您需要为它实现 deferred（就像我为 tipfy 做的 here 一样）。

其他处理程序也会发生同样的情况：blobstore（Werkzeug 仍然不支持范围请求，因此即使您创建自己的处理程序，您也需要使用 WebOb ——请参阅tipfy.appengine.blobstore）、邮件、XMPP 等，或将来包含在 SDK 中的其他内容。

同样的情况也发生在使用 App Engine 创建的库中，例如 ProtoRPC，它基于 webapp，如果您不想混合使用 webapp 和您的-同一应用程序中的选择框架处理程序。

因此，即使您选择不同的框架，您也将结束 a) 在某些特殊情况下使用 webapp 或 b) 必须为特定的 SDK 处理程序或功能创建和维护您的版本（如果您将使用它们）。

我更喜欢 Werkzeug 而不是 WebOb，但是在移植和维护原生与 Tipfy 一起工作的 SDK 处理程序版本一年多之后，我意识到这是一个失败的原因——要长期支持 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！
@Sundar 它可以在任何符合 WSGI 的 Web 服务器上运行。对于 Apache，有 code.google.com/p/modwsgi 等。
@moraes：这个答案现在过时了吗？我可以看到 GAE SDK 支持 Flask。 webapp2 还是更好的选择吗？
@nish，提到GAE SDK官方支持Flask？
请注意，虽然这是公认的传统答案，但 webapp2 开发已死。我会说 Flask 是要走的路。

【解决方案3】：

当我发现flask 不是一个面向对象的框架（从一开始），而webapp2 是一个纯面向对象的框架时，对我来说选择webapp2 很容易。 webapp2 使用基于方法的调度作为所有 RequestHandlers 的标准（因为烧瓶文档调用它并在 MethodViews 中自 V0.7 起实现它）。虽然在烧瓶中 MethodViews 是一个附加组件，但它是 webapp2 的核心设计原则。因此，使用这两种框架，您的软件设计看起来会有所不同。这两个框架都使用现在的 jinja2 模板，并且功能完全相同。

我更喜欢向基类 RequestHandler 添加安全检查并从它继承。这对于实用程序功能等也很有用。正如您在链接 [3] 中看到的示例，您可以覆盖方法以防止分派请求。

如果你是一个面向对象的人，或者如果你需要设计一个 REST 服务器，我会为你推荐 webapp2。如果您更喜欢使用装饰器的简单函数作为多种请求类型的处理程序，或者您对 OO 继承感到不舒服，那么选择 flask。我认为这两个框架都避免了金字塔等更大框架的复杂性和依赖性。

【讨论】：

就是这样，OOP 支持赢得了我。我最初使用 web.py，但 webapp2 似乎结构简洁，没有我在 web.py 上所做的解决方法。烧瓶可能很容易开始，但如果你打算制作更大的应用程序，你需要的还不止这些

【解决方案4】：

我认为谷歌应用引擎正式支持烧瓶框架。这里有示例代码和教程 -> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855

【讨论】：

对我来说，这不是官方支持，这只是“你也可以用 Flask 来做”的例子——风格。对于 webapp2，仍然有详细的手册，在这里和那里添加了 GAE 特定的项目。

【解决方案5】：

您的问题非常广泛，但在 Google App Engine 上使用 Flask 似乎没有什么大问题。

这个邮件列表线程链接到几个模板：

http://flask.pocoo.org/mailinglist/archive/2011/3/27/google-app-engine/#4f95bab1627a24922c60ad1d0a0a8e44

这里有一个专门针对 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，请求主观个人体验非常接近questions not to ask 的 SO 准则。
@James - 不同意。我不会询问你的猜测、假设或主观感受。我询问您的经验，即您确信知道的事实。不是过时的帖子，也不是其他人在大量定制过程中遇到的问题，只是事实。不同意 - 好吧，只是标记它。