Flask和webapp2在Google App Engine中的比较

Question

Flask和webapp2在Google App Engine中的比较

117

我正在创建一个新的Google App Engine应用程序，目前考虑两个框架：Flask和webapp2。我之前使用过内置的webapp框架制作过应用程序，对它很满意，所以我认为webapp2会更好，并且我不会遇到任何问题。

但是，有很多关于Flask的好评，我真的很喜欢它的方法和所有文档中读到的东西，我想试一试。但我有些担心在使用Flask时可能会面临的限制。

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

作为后续问题：您认为Flask有哪些杀手功能可以让我惊艳并让我使用它，尽管我可能会面临任何问题？

- Anton Moiseev

我对webapp2不是很了解，但我已经使用Flask几个月了，我非常喜欢它。我发现了一些真正帮助我的Flask插件，例如flask-babel用于多语言支持，以及flask-seasurf用于CSRF支持以保护我的表单。 - ThePloki

5个回答

13

您的问题非常广泛，但似乎在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

7

谢谢，@agf。我之前看过这些帖子中的大部分内容，但我认为我更感兴趣的是个人经验。我不觉得这个问题太过宽泛，因为我并不想进行全面讨论或详细了解问题的信息，只需指出实现这个和那个可能会很困难或不可能即可。 - Anton Moiseev

2

@Anton，请求主观个人经验与不应提问的问题几乎接近SO指南。 - James

9

@James- 不同意。我不询问您的猜测、假设或主观感受。我询问您的经验，即您自信知道的事实。不是过时的帖子，也不是其他人在进行大量定制时遇到的问题，只是事实。如果您不同意，请标记它。 - Anton Moiseev

3

对于我来说，选择webapp2很容易，因为我发现flask不是一个面向对象的框架（从一开始就不是），而webapp2是一个纯面向对象的框架。 webapp2将基于方法的分派作为所有RequestHandlers的标准使用（正如flask文档所称，并自V0.7以来在MethodViews中实现）。而在flask中，MethodViews是一个附加组件，它是webapp2的核心设计原则。因此，使用这两个框架时，您的软件设计将会有所不同。这两个框架都使用jinja2模板，并且功能基本相同。

我喜欢将安全检查添加到基类RequestHandler中并继承它。这也适用于实用程序函数等。例如，您可以在链接[3]中看到，可以重写方法以防止分派请求。

如果您是面向对象的人，或者需要设计REST服务器，则建议您选择webapp2。如果您喜欢具有装饰器的简单函数作为多个请求类型的处理程序，或者您不熟悉OO继承，则选择flask。我认为这两个框架都避免了像pyramid这样更大框架的复杂性和依赖关系。

- cat

就是这样，面向对象编程的支持让我选择了它。我最初使用的是web.py，但webapp2似乎有更整洁的结构，不需要我在web.py上进行的变通处理。Flask可能很容易入门，但如果您计划制作更大的应用程序，那就需要更多的东西。 - Ahmad Muzakki

2

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

- Anup

对我来说，这不是官方支持，这只是一个“你也可以用Flask做到”的例子。对于webapp2，仍然有详细的手册，并在其中添加了GAE特定的项目。 - silpol

2

我没有尝试过webapp2，而且发现tipfy有点难用，因为它需要设置脚本和构建，以配置你的Python安装到非默认位置。出于这些和其他原因，我没有让我的最大项目依赖框架，而是使用了普通的webapp，添加了名为beaker的库以获取会话功能，而django已经内置了对许多用例常见单词的翻译，因此在构建本地化应用程序时，django是我最大项目的正确选择。我实际部署过两个框架的项目到生产环境中，分别是GAEframework.com和web2py，总的来说，添加一个改变其模板引擎的框架可能会导致旧版本和新版本之间的不兼容性。

所以我的经验是，除非解决更高级的用例（文件上传、多身份验证、管理UI是3个目前没有框架能很好处理的更高级用例），否则我会不太愿意将框架添加到我的项目中。

- Niklas Rosencrantz

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- moraes · Accepted Answer

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

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

例如，deferred使用webapp处理程序。要在纯Flask视图中使用它，使用werkzeug.Request和werkzeug.Response，您需要为其实现延迟（就像我在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防御策略。另外，webapp2可以在App Engine之外使用并且可以轻松自定义以看起来像流行的微框架，这些都是选择它的令人信服的理由。而且，webapp2有很大机会被包含在未来的SDK发布中（这是额外的非官方信息，请勿引用我 :-)），这将推动它向前发展并带来新的开发人员和贡献。

尽管如此，我非常喜欢Werkzeug和Pocoo团队，并从Flask和其他框架（如web.py和Tornado）中借鉴了很多东西。但是，以上提到的webapp2的优点应该被考虑在内。