I'm starting new Google App Engine application and currently considering two frameworks: Flask and webapp2. I'm rather satisfied with built-in webapp framework that I've used for my previous App Engine application, so I think webapp2 will be even better and I won't have any problems with it.
我正在启动新的谷歌应用程序引擎应用程序，目前正在考虑两个框架:Flask和webapp2。我对之前应用引擎应用中使用的内置webapp框架非常满意，所以我认为webapp2会更好，不会有任何问题。
However, there are a lot of good reviews of Flask, I really like its approach and all the things that I've read so far in the documentation and I want to try it out. But I'm a bit concerned about limitations that I can face down the road with Flask.
但是，Flask有很多不错的评论，我非常喜欢它的方法，以及到目前为止我在文档中读到的所有东西，我想尝试一下。但是我有点担心我可以用烧瓶面对的局限性。
So, the question is - do you know any problems, performance issues, limitations (e.g. routing system, built-in authorization mechanism, etc.) that Flask could bring into Google App Engine application? By "problem" I mean something that I can't work around in several lines of code (or any reasonable amount of code and efforts) or something that is completely impossible.
所以，问题是——你知道Flask会给谷歌应用程序引擎带来什么问题、性能问题、限制(比如路由系统、内置授权机制等)吗?我所说的“问题”是指在几行代码(或任何合理数量的代码和工作)中无法处理的东西，或者是完全不可能处理的东西。
And as a follow-up question: are there any killer-features in Flask that you think can blow my mind and make me use it despite any problems that I can face?
作为一个后续的问题:在Flask中是否存在一些killer特性，你认为它会让我的头脑崩溃，让我使用它，尽管我可以面对任何问题?
5 个解决方案
#1
135
Disclaimer: I'm the author of tipfy and webapp2.
免责声明:我是tipfy和webapp2的作者。
A big advantage of sticking with webapp (or its natural evolution, webapp2) is that you don't have to create your own versions for existing SDK handlers for your framework of your choice.
坚持使用webapp(或者它的自然演变，webapp2)的一大优点是，您不必为您所选择的框架创建自己的版本。
For example, deferred uses a webapp handler. To use it in a pure Flask view, using werkzeug.Request and werkzeug.Response, you'll need to implement deferred for it (like I did here for tipfy).
例如，deferred使用的是webapp处理器。在纯Flask视图中使用它，使用werkzeug。请求和werkzeug。响应，您需要为它实现deferred(就像我在这里为tipfy所做的那样)。
The same happens for other handlers: blobstore (Werkzeug still doesn't support range requests, so you'll need to use WebOb even if you create your own handler -- see tipfy.appengine.blobstore), mail, XMPP and so on, or others that are included in the SDK in the future.
对于其他处理程序也是如此:blobstore (Werkzeug仍然不支持范围请求，因此即使您创建了自己的处理程序(参见tipfy.appengine.blobstore)、mail、XMPP等等，或者将来SDK中包含的其他处理程序，您也需要使用WebOb。
And the same happens for libraries created with App Engine in mind, like ProtoRPC, which is based on webapp and would need a port or adapter to work with other frameworks, if you don't want to mix webapp and your-framework-of-choice handlers in the same app.
应用程序引擎创建的库也会遇到同样的情况，比如ProtoRPC，它基于webapp，如果你不想在同一个应用程序中混合webapp和你的框架选择处理器，它需要一个端口或适配器来与其他框架协同工作。
So, even if you choose a different framework, you'll end a) using webapp in some special cases or b) having to create and maintain your versions for specific SDK handlers or features, if you'll use them.
因此，即使您选择了一个不同的框架，您也将结束a)在某些特殊情况下使用webapp，或者b)必须为特定的SDK处理程序或特性创建和维护您的版本，如果您要使用它们的话。
I much prefer Werkzeug over WebOb, but after over one year porting and maintaining versions of the SDK handlers that work natively with tipfy, I realized that this is a lost cause -- to support GAE for the long term, best is to stay close to webapp/WebOb. It makes support for SDK libraries a breeze, maintenance becomes a lot easier, it is more future-proof as new libraries and SDK features will work out of the box and there's the benefit of a large community working around the same App Engine tools.
我更喜欢Werkzeug而不是WebOb，但是在移植和维护使用tipfy的SDK处理程序的版本超过一年之后，我意识到这是一个失败的原因——为了长期支持GAE，最好是保持与webapp/WebOb的接近。它使得对SDK库的支持变得更加容易，维护变得更加容易，因为新的库和SDK特性将会在这个框架中发挥作用，并且在同一个应用程序引擎工具周围有一个大社区的好处。
A specific webapp2 defense is summarized here. Add to those that webapp2 can be used outside of App Engine and is easy to be customized to look like popular micro-frameworks and you have a good set of compelling reasons to go for it. Also, webapp2 has a big chance to be included in a future SDK release (this is extra-official, don't quote me :-) which will push it forward and bring new developers and contributions.
这里总结了一个特定的webapp2防御。除此之外，webapp2还可以在App Engine之外使用，而且很容易定制，使其看起来像流行的微框架，而且你有充分的理由去使用它。此外，webapp2有很大的机会被包含在未来的SDK版本中(这是官方的，不要引用我的话:-)，这将推动它向前发展，并带来新的开发人员和贡献。
That said, I'm a big fan of Werkzeug and the Pocoo guys and borrowed a lot from Flask and others (web.py, Tornado), but -- and, you know, I'm biased -- the above webapp2 benefits should be taken into account.
话虽如此，我还是沃切克和Pocoo的忠实粉丝，并从Flask和其他人那里借了很多(网络)。但是——而且，你知道，我有偏见——应该考虑到上面webapp2的好处。
#2
12
Your question is extremely broad, but there appears to be no big problems using Flask on Google App Engine.
您的问题非常广泛，但是在谷歌应用程序引擎上使用Flask似乎没有什么大问题。
This mailing list thread links to several templates:
这个邮件列表链接到几个模板:
http://flask.pocoo.org/mailinglist/archive/2011/3/27/google-app-engine/ # 4 f95bab1627a24922c60ad1d0a0a8e44
And here is a tutorial specific to the Flask / App Engine combination:
这里有一个针对Flask / App引擎组合的教程:
http://www.franciscosouza.com/2010/08/flying-with-flask-on-google-app-engine/
http://www.franciscosouza.com/2010/08/flying-with-flask-on-google-app-engine/
Also, see App Engine - Difficulty Accessing Twitter Data - Flask, Flask message flashing fails across redirects, and How do I manage third-party Python libraries with Google App Engine? (virtualenv? pip?) for issues people have had with Flask and Google App Engine.
另外，请参见App Engine—难以访问Twitter数据—Flask、Flask消息在重定向时闪烁失败，以及如何使用谷歌应用程序引擎管理第三方Python库?(virtualenv ?对于人们在Flask和谷歌应用程序引擎上遇到的问题。
#3
2
I think google app engine officially supports flask framework. There is a sample code and tutorial here -> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855
我认为谷歌app engine正式支持flask框架。这里有一个示例代码和教程——> https://console.developers.google.com/start/appengine?
#4
2
For me the decision for webapp2 was easy when I discovered that flask is not an object-oriented framework (from the beginning), while webapp2 is a pure object oriented framework. webapp2 uses Method Based Dispatching as standard for all RequestHandlers (as flask documentation calls it and implements it since V0.7 in MethodViews). While in flask MethodViews are an add-on it is a core design principle for webapp2. So your software design will look different using both frameworks. Both frameworks use nowadays jinja2 templates and are fairly feature identical.
对我来说，当我发现flask不是一个面向对象的框架(从一开始)，而webapp2是一个纯面向对象的框架时，webapp2的决定就很容易了。webapp2使用基于方法的分派作为所有RequestHandlers的标准(flask文档调用它并在MethodViews中实现V0.7)。flask MethodViews是一个附加组件，它是webapp2的核心设计原则。因此，使用这两个框架，您的软件设计将看起来有所不同。这两个框架现在都使用jinja2模板，并且功能完全相同。
I prefer to add security checks to a base-class RequestHandler and inherit from it. This is also good for utility functions, etc. As you can see for example in link [3] you can override methods to prevent dispatching a request.
我更喜欢将安全检查添加到基类RequestHandler并从中继承。这对实用功能也有好处，等等。如您在链接[3]中看到的，您可以重写方法以防止发送请求。
If you are an OO-person, or if you need to design a REST-server, I would recommend webapp2 for you. If you prefer simple functions with decorators as handlers for multiple request-types, or you are uncomfortable with OO-inheritance then choose flask. I think both frameworks avoid the complexity and dependencies of much bigger frameworks like pyramid.
如果您是OO-person，或者需要设计REST-server，我将为您推荐webapp2。如果您喜欢使用修饰符的简单函数作为多个请求类型的处理程序，或者您对oo继承感到不舒服，那么选择flask。我认为这两个框架都避免了像金字塔这样的大型框架的复杂性和依赖性。
- http://flask.pocoo.org/docs/0.10/views/#method-based-dispatching
- http://flask.pocoo.org/docs/0.10/views/ method-based-dispatching
- https://webapp-improved.appspot.com/guide/handlers.html
- https://webapp-improved.appspot.com/guide/handlers.html
- https://webapp-improved.appspot.com/guide/handlers.html#overriding-dispatch
- https://webapp-improved.appspot.com/guide/handlers.html overriding-dispatch
#5
1
I didn't try webapp2 and found that tipfy was a bit difficult to use since it required setup scripts and builds that configure your python installation to other than default. För these and other reasons I havn't made my largest project depend on a framework and I use the plain webapp instead, add the library called beaker to get session capability and django already has builtin translations for words common to many usecases so when building a localized application django was the right choice for my largest project. The 2 other frameworks I actually deployed with projects to a production environment were GAEframework.com and web2py and generally it seems that adding a framework which changes its template engine could lead to incompatibilities between old and new versions.
我没有尝试webapp2，发现使用tipfy有点困难，因为它需要安装脚本和构建，将python安装配置为默认设置之外。由于这些和其他原因我没有让我和最大的项目依赖于一个框架使用普通webapp相反,添加库称为烧杯会话能力和django已经装入的翻译词常见许多可变性当构建本地化应用程序django我最大的项目是正确的选择。我实际部署到生产环境的另外两个框架是GAEframework.com和web2py，一般来说，添加一个修改模板引擎的框架可能会导致新旧版本之间的不兼容。
So my experience is that I'm being reluctant to adding a framework to my projects unless they solve the more advanced use cases (file upload, multi auth, admin ui are 3 examples of more advanced use cases that no framework for gae at the moment handles well.
因此，我的经验是，我不愿意在我的项目中添加框架，除非它们解决了更高级的用例(文件上传、多身份、管理ui是3个更高级的用例，目前gae没有一个框架能够很好地处理这些用例。
#1
135
Disclaimer: I'm the author of tipfy and webapp2.
免责声明:我是tipfy和webapp2的作者。
A big advantage of sticking with webapp (or its natural evolution, webapp2) is that you don't have to create your own versions for existing SDK handlers for your framework of your choice.
坚持使用webapp(或者它的自然演变，webapp2)的一大优点是，您不必为您所选择的框架创建自己的版本。
For example, deferred uses a webapp handler. To use it in a pure Flask view, using werkzeug.Request and werkzeug.Response, you'll need to implement deferred for it (like I did here for tipfy).
例如，deferred使用的是webapp处理器。在纯Flask视图中使用它，使用werkzeug。请求和werkzeug。响应，您需要为它实现deferred(就像我在这里为tipfy所做的那样)。
The same happens for other handlers: blobstore (Werkzeug still doesn't support range requests, so you'll need to use WebOb even if you create your own handler -- see tipfy.appengine.blobstore), mail, XMPP and so on, or others that are included in the SDK in the future.
对于其他处理程序也是如此:blobstore (Werkzeug仍然不支持范围请求，因此即使您创建了自己的处理程序(参见tipfy.appengine.blobstore)、mail、XMPP等等，或者将来SDK中包含的其他处理程序，您也需要使用WebOb。
And the same happens for libraries created with App Engine in mind, like ProtoRPC, which is based on webapp and would need a port or adapter to work with other frameworks, if you don't want to mix webapp and your-framework-of-choice handlers in the same app.
应用程序引擎创建的库也会遇到同样的情况，比如ProtoRPC，它基于webapp，如果你不想在同一个应用程序中混合webapp和你的框架选择处理器，它需要一个端口或适配器来与其他框架协同工作。
So, even if you choose a different framework, you'll end a) using webapp in some special cases or b) having to create and maintain your versions for specific SDK handlers or features, if you'll use them.
因此，即使您选择了一个不同的框架，您也将结束a)在某些特殊情况下使用webapp，或者b)必须为特定的SDK处理程序或特性创建和维护您的版本，如果您要使用它们的话。
I much prefer Werkzeug over WebOb, but after over one year porting and maintaining versions of the SDK handlers that work natively with tipfy, I realized that this is a lost cause -- to support GAE for the long term, best is to stay close to webapp/WebOb. It makes support for SDK libraries a breeze, maintenance becomes a lot easier, it is more future-proof as new libraries and SDK features will work out of the box and there's the benefit of a large community working around the same App Engine tools.
我更喜欢Werkzeug而不是WebOb，但是在移植和维护使用tipfy的SDK处理程序的版本超过一年之后，我意识到这是一个失败的原因——为了长期支持GAE，最好是保持与webapp/WebOb的接近。它使得对SDK库的支持变得更加容易，维护变得更加容易，因为新的库和SDK特性将会在这个框架中发挥作用，并且在同一个应用程序引擎工具周围有一个大社区的好处。
A specific webapp2 defense is summarized here. Add to those that webapp2 can be used outside of App Engine and is easy to be customized to look like popular micro-frameworks and you have a good set of compelling reasons to go for it. Also, webapp2 has a big chance to be included in a future SDK release (this is extra-official, don't quote me :-) which will push it forward and bring new developers and contributions.
这里总结了一个特定的webapp2防御。除此之外，webapp2还可以在App Engine之外使用，而且很容易定制，使其看起来像流行的微框架，而且你有充分的理由去使用它。此外，webapp2有很大的机会被包含在未来的SDK版本中(这是官方的，不要引用我的话:-)，这将推动它向前发展，并带来新的开发人员和贡献。
That said, I'm a big fan of Werkzeug and the Pocoo guys and borrowed a lot from Flask and others (web.py, Tornado), but -- and, you know, I'm biased -- the above webapp2 benefits should be taken into account.
话虽如此，我还是沃切克和Pocoo的忠实粉丝，并从Flask和其他人那里借了很多(网络)。但是——而且，你知道，我有偏见——应该考虑到上面webapp2的好处。
#2
12
Your question is extremely broad, but there appears to be no big problems using Flask on Google App Engine.
您的问题非常广泛，但是在谷歌应用程序引擎上使用Flask似乎没有什么大问题。
This mailing list thread links to several templates:
这个邮件列表链接到几个模板:
http://flask.pocoo.org/mailinglist/archive/2011/3/27/google-app-engine/ # 4 f95bab1627a24922c60ad1d0a0a8e44
And here is a tutorial specific to the Flask / App Engine combination:
这里有一个针对Flask / App引擎组合的教程:
http://www.franciscosouza.com/2010/08/flying-with-flask-on-google-app-engine/
http://www.franciscosouza.com/2010/08/flying-with-flask-on-google-app-engine/
Also, see App Engine - Difficulty Accessing Twitter Data - Flask, Flask message flashing fails across redirects, and How do I manage third-party Python libraries with Google App Engine? (virtualenv? pip?) for issues people have had with Flask and Google App Engine.
另外，请参见App Engine—难以访问Twitter数据—Flask、Flask消息在重定向时闪烁失败，以及如何使用谷歌应用程序引擎管理第三方Python库?(virtualenv ?对于人们在Flask和谷歌应用程序引擎上遇到的问题。
#3
2
I think google app engine officially supports flask framework. There is a sample code and tutorial here -> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855
我认为谷歌app engine正式支持flask框架。这里有一个示例代码和教程——> https://console.developers.google.com/start/appengine?
#4
2
For me the decision for webapp2 was easy when I discovered that flask is not an object-oriented framework (from the beginning), while webapp2 is a pure object oriented framework. webapp2 uses Method Based Dispatching as standard for all RequestHandlers (as flask documentation calls it and implements it since V0.7 in MethodViews). While in flask MethodViews are an add-on it is a core design principle for webapp2. So your software design will look different using both frameworks. Both frameworks use nowadays jinja2 templates and are fairly feature identical.
对我来说，当我发现flask不是一个面向对象的框架(从一开始)，而webapp2是一个纯面向对象的框架时，webapp2的决定就很容易了。webapp2使用基于方法的分派作为所有RequestHandlers的标准(flask文档调用它并在MethodViews中实现V0.7)。flask MethodViews是一个附加组件，它是webapp2的核心设计原则。因此，使用这两个框架，您的软件设计将看起来有所不同。这两个框架现在都使用jinja2模板，并且功能完全相同。
I prefer to add security checks to a base-class RequestHandler and inherit from it. This is also good for utility functions, etc. As you can see for example in link [3] you can override methods to prevent dispatching a request.
我更喜欢将安全检查添加到基类RequestHandler并从中继承。这对实用功能也有好处，等等。如您在链接[3]中看到的，您可以重写方法以防止发送请求。
If you are an OO-person, or if you need to design a REST-server, I would recommend webapp2 for you. If you prefer simple functions with decorators as handlers for multiple request-types, or you are uncomfortable with OO-inheritance then choose flask. I think both frameworks avoid the complexity and dependencies of much bigger frameworks like pyramid.
如果您是OO-person，或者需要设计REST-server，我将为您推荐webapp2。如果您喜欢使用修饰符的简单函数作为多个请求类型的处理程序，或者您对oo继承感到不舒服，那么选择flask。我认为这两个框架都避免了像金字塔这样的大型框架的复杂性和依赖性。
- http://flask.pocoo.org/docs/0.10/views/#method-based-dispatching
- http://flask.pocoo.org/docs/0.10/views/ method-based-dispatching
- https://webapp-improved.appspot.com/guide/handlers.html
- https://webapp-improved.appspot.com/guide/handlers.html
- https://webapp-improved.appspot.com/guide/handlers.html#overriding-dispatch
- https://webapp-improved.appspot.com/guide/handlers.html overriding-dispatch
#5
1
I didn't try webapp2 and found that tipfy was a bit difficult to use since it required setup scripts and builds that configure your python installation to other than default. För these and other reasons I havn't made my largest project depend on a framework and I use the plain webapp instead, add the library called beaker to get session capability and django already has builtin translations for words common to many usecases so when building a localized application django was the right choice for my largest project. The 2 other frameworks I actually deployed with projects to a production environment were GAEframework.com and web2py and generally it seems that adding a framework which changes its template engine could lead to incompatibilities between old and new versions.
我没有尝试webapp2，发现使用tipfy有点困难，因为它需要安装脚本和构建，将python安装配置为默认设置之外。由于这些和其他原因我没有让我和最大的项目依赖于一个框架使用普通webapp相反,添加库称为烧杯会话能力和django已经装入的翻译词常见许多可变性当构建本地化应用程序django我最大的项目是正确的选择。我实际部署到生产环境的另外两个框架是GAEframework.com和web2py，一般来说，添加一个修改模板引擎的框架可能会导致新旧版本之间的不兼容。
So my experience is that I'm being reluctant to adding a framework to my projects unless they solve the more advanced use cases (file upload, multi auth, admin ui are 3 examples of more advanced use cases that no framework for gae at the moment handles well.
因此，我的经验是，我不愿意在我的项目中添加框架，除非它们解决了更高级的用例(文件上传、多身份、管理ui是3个更高级的用例，目前gae没有一个框架能够很好地处理这些用例。