用于Google App Engine的Flask vs webapp2
我正在开发新的Google App Engine应用程序，目前正在考虑两个框架： Flask和webapp2 。 我对用于以前的App Engine应用程序的内置的webapp框架感到满意，所以我认为webapp2会更好，我也不会有任何问题。
然而，Flask有很多好的评论，我非常喜欢它的方法以及我在文档中已经阅读过的所有东西，我想试试看。 但是我有点担心我能用Flask面对这个道路的局限性。
所以，问题是 – 您是否知道Flask可能会带入Google App Engine应用程序的任何问题，性能问题，限制（例如路由系统，内置授权机制等）？ “问题”指的是我不能在几行代码（或任何合理数量的代码和努力）中解决的问题，或者是完全不可能的东西。
作为一个后续的问题：在Flask中是否有任何杀手级的特性，尽pipe我可以面对任何问题，但是您认为这些特性可能会让我失望并让我使用它。
免责声明：我是tipfy和webapp2的作者。
坚持使用webapp（或其自然发展，webapp2）的一大优势是，您不必为您select的框架为现有SDK处理程序创build自己的版本。
例如， 延迟使用webapp处理程序。 要在纯Flask视图中使用它，使用werkzeug.Request和werkzeug.Response，你需要实现延期（就像我在这里为tipfy）。
其他处理程序也会发生同样的情况：blobstore（Werkzeug仍然不支持范围请求，因此，即使您创build了自己的处理程序，请参阅tipfy.appengine.blobstore ），邮件，XMPP等，或将来包含在SDK中的其他人。
对于使用App Engine创build的库来说也是一样，比如基于webapp的ProtoRPC ，如果你不想把webapp和你的框架混合在一起，需要一个端口或者适配器来与其他框架一起工作。在同一个应用程序的select处理程序。
所以，即使你select了一个不同的框架，你也可以在一些特殊的情况下使用webapp，或者b）为特定的SDK处理器或者特性创build和维护你的版本，如果你使用的话。
我非常喜欢Werkzeug，而不是WebOb，但是经过一年多的移植和维护版本的SDK处理程序，本身使用tipfy，我意识到这是一个失败的原因 – 为了长期支持GAE，最好是保持接近Web应用程序/的WebOb。 它使得对SDK库的支持变得轻而易举，维护变得更容易，因为新的库和SDKfunction可以开箱即用，并且围绕相同的App Engine工具开发的大型社区的好处更为明显。
这里总结了一个特定的webapp2防御。 除此之外 ， webapp2可以在App Engine之外使用，并且很容易被定制成stream行的微框架，而且你有很多令人信服的理由。 此外，webapp2有一个很大的机会被纳入未来的SDK版本（这是非官方的，不要引用我:-)这将推动它，并带来新的开发者和贡献。
也就是说，我是Werkzeug和Pocoo家伙的忠实粉丝，他们从Flask和其他人（web.py，Tornado）借了很多，但是 – 你知道，我有偏见 – 上面的webapp2好处应该是被考虑在内。
您的问题非常广泛，但在Google App Engine上使用Flask似乎没有大问题。
这个邮件列表线程链接到几个模板：
这里是一个专门针对Flask / App Engine组合的教程：
http://www.franciscosouza.com/2010/08/flying-with-flask-on-google-app-engine/
此外，请参阅App引擎 – 访问Twitter数据时遇到困难 – Flask ， Flask消息在redirect中闪烁失败 ，以及如何使用Google App Enginepipe理第三方Python库？ （virtualenv？pip？）解决了人们在Flask和Google App Engine中遇到的问题。
我认为谷歌应用程序引擎正式支持瓶框架。 这里有一个示例代码和教程 – > https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855
对我来说，当我发现烧瓶不是一个面向对象的框架（从一开始），而webapp2是一个纯粹的面向对象的框架的时候，webapp2的决定是很容易的。 webapp2使用基于方法的调度作为所有RequestHandlers的标准（因为flask文档从MethodViews中的V0.7开始调用它并实现它）。 在烧瓶中，MethodViews是一个附加组件，它是webapp2的核心devise原则。 所以你的软件devise看起来不同，使用这两个框架。 这两个框架使用时下jinja2模板和相当相同的function。
我更喜欢将安全检查添加到基类RequestHandler并从中inheritance。 这对于实用程序function等也是很好的。正如您可以在链接[3]中看到的那样，您可以覆盖防止调度请求的方法。
如果你是一个面向对象的人，或者如果你需要devise一个REST服务器，我会为你推荐webapp2。 如果你喜欢装饰器的简单函数作为多个请求types的处理程序，或者你不习惯OOinheritance，那么selectflask。 我认为这两个框架避免了像金字塔这样的更大框架的复杂性和依赖性。
我没有尝试webapp2，发现tipfy有点难以使用，因为它需要安装脚本和构buildconfiguration您的python安装非默认。 由于这些和其他原因，我没有做出我最大的项目取决于一个框架，我使用普通的webapp，而不是增加名为烧杯的库来获得会话能力和django已经有内置的翻译许多用例共同的话，所以当build立一个本地化应用django是我最大的项目的正确select。 我实际部署到项目中的其他两个框架是GAEframework.com和web2py，通常添加一个改变其模板引擎的框架可能导致新旧版本之间的不兼容。
所以我的经验是，我不愿意为我的项目添加一个框架，除非他们解决了更高级的用例（file upload，多重authentication，pipe理员用户是目前没有gae框架的更高级用例的3个例子处理得好。
