Flask vs webapp2(适用于Google App Engine)


116

我正在启动新的Google App Engine应用程序,目前正在考虑两个框架:Flaskwebapp2。我对以前的App Engine应用程序使用的内置webapp框架感到非常满意,因此我认为webapp2会更好,并且不会有任何问题。

但是,Flask有很多不错的评论,我真的很喜欢Flask的方法以及到目前为止我在文档中已经读过的所有东西,我想尝试一下。但是我有点担心Flask会遇到的局限性。

因此,问题是- 您是否知道Flask可能会带入Google App Engine应用程序的任何问题,性能问题,限制(例如,路由系统,内置授权机制等)?“问题”是指我无法在几行代码(或任何合理数量的代码和工作量)中解决的问题,或者是完全不可能的事情。

还有一个后续问题:尽管我可能会遇到任何问题,但您认为Flask中是否有任何杀手级功能可以打动我,让我使用它?


我对webapp2不太了解,但是我已经使用Flask几个月了,我喜欢它。我发现烧瓶插件确实对我有所帮助,例如flask-babel多语言支持以及flask-seasurfCSRF支持以保护我的表格。
ThePloki '16

Answers:


138

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

坚持使用webapp(或其自然发展版本,webapp2)的一大优势是,您不必为自己选择的框架为现有的SDK处理程序创建自己的版本。

例如,deferred使用一个webapp处理程序。要在纯Flask视图中使用werkzeug.Request和werkzeug.Response来使用它,您需要为此实现deferred(就像我在这里为tipfy 所做的那样)。

其他处理程序也会发生同样的情况:blobstore(Werkzeug仍然不支持范围请求,因此即使您创建了自己的处理程序,也需要使用WebOb -请参见tipfy.appengine.blobstore),邮件,XMPP等,或以后包含在SDK中的其他内容。

对于使用App Engine创建的库,也是如此,例如ProtoRPC,它基于webapp,并且如果您不想混合使用webapp和框架,则需要端口或适配器才能与其他框架一起使用。同一应用中的选择处理程序。

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

与WebOb相比,我更偏爱Werkzeug,但是在移植和维护可与Tipfy一起使用的SDK处理程序版本超过一年之后,我意识到这是一个失败的原因-长期支持GAE,最好是保持与webapp / WebOb。它使对SDK库的支持变得轻而易举,维护变得更加容易,因为新的库和SDK功能将立即可用,因此它具有更强的前瞻性,并且大型社区可以使用相同的App Engine工具来受益。

这里总结一个特定的webapp2防御。此外,webapp2可以在App Engine之外使用,并且易于自定义以使其看起来像流行的微框架,并且您有很多吸引人的理由。而且,webapp2有很大的机会被包含在将来的SDK版本中(这是非正式的,不要引用我的:-),这将推动它向前发展并带来新的开发人员和贡献。

也就是说,我是Werkzeug和Pocoo的忠实拥护者,并向Flask和其他人(web.py,Tornado)借了很多钱,但是-我知道,我有偏见-以上webapp2的好处应该被考虑在内。


10
谢谢,@ moraes!足够坚固。我认为诸如blobstore,邮件(可能还有ProtoRPC)之类的东西对于该项目来说非常重要,我想尽可能地与它们一起工作。另外,我认为混合不同的框架不是最好的主意,如果您可以轻松避免的话。而且,尽管我对Flask表示同情,但是webapp2确实给我留下了深刻的印象,并且动手尝试了它。感谢您的回答和webapp2!
安东·莫谢耶夫

3
@Sundar可以在任何符合WSGI的Web服务器上运行。对于Apache,有code.google.com/p/modwsgi和其他代码。
moraes 2011年

4
@moraes:这个答案现在过时了吗?我可以看到GAE SDK支持Flask。webapp2还是更好的选择吗?
2014年

1
@ nish,GAE SDK正式支持Flask的参考吗?
恩卡什

15
请注意,尽管这是公认的传统答案,但是webapp2开发已死了。我会说Flask是要走的路。
杰西

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-难以访问Twitter数据-FlaskFlask消息刷新无法跨重定向重定向,以及如何使用Google App Engine管理第三方Python库?(virtualenv?pip?)解决人们对于Flask和Google App Engine的问题。


7
谢谢,@ agf。我以前看过大多数此类文章,但我想我对个人经历更感兴趣。我不认为这个问题太过广泛,因为我对全面讨论或关于某个问题的详细信息不感兴趣,请指出这一点,这将很难或不可能实现。
安东·莫谢耶夫

2
@Anton,要求主观的个人经历非常接近SO准则,以解决不问的问题
詹姆斯

9
@詹姆斯-不同意。我不问您关于您的猜测,假设或主观感受的信息。我问您的经历,即您自信地知道的事实。不是过时的帖子,也不是其他人在大量定制期间遇到的问题,这只是事实。不同意-好的,只需对其进行标记。
安东·莫谢耶夫

3

对我来说,当我发现烧瓶不是(从一开始就)不是面向对象的框架,而webapp2是一个纯粹的面向对象的框架时,对webapp2的决定很容易。webapp2将基于方法的调度作为所有RequestHandler的标准使用(如烧瓶文档在MethodViews中从V0.7开始对其进行调用和实现)。在烧瓶中,MethodViews是附加组件,它是webapp2的核心设计原则。因此,使用这两种框架,您的软件设计将看起来有所不同。如今,这两个框架都使用jinja2模板,并且功能完全相同。

我更喜欢将安全检查添加到基类RequestHandler并从中继承。这对于实用程序功能等也很有用。例如,您可以在链接[3]中看到,您可以重写方法以防止调度请求。

如果您是面向对象的人,或者需要设计REST服务器,我将为您推荐webapp2。如果您希望使用带有装饰器的简单函数作为多种请求类型的处理程序,或者对OO继承不满意,请选择flask。我认为这两个框架都避免了金字塔等大型框架的复杂性和依赖性。

  1. http://flask.pocoo.org/docs/0.10/views/#method-based-dispatching
  2. https://webapp-improved.appspot.com/guide/handlers.html
  3. https://webapp-improved.appspot.com/guide/handlers.html#overriding-dispatch

就是这样,OOP支持赢得了我。我最初使用的是web.py,但webapp2似乎结构整齐,没有在web.py上执行的解决方法。flask可能很容易启动,但是如果您打算制作更大的应用程序,则需要更多的信息
Ahmad Muzakki '16


2

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

因此,我的经验是,除非他们解决了更高级的用例(文件上传,多重身份验证,管理ui是目前尚无框架的3个更高级的用例示例),否则我不愿意在项目中添加框架处理得很好。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.