117

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.

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.

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.

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?

davidism
  • 121,510
  • 29
  • 395
  • 339
Anton Moiseev
  • 2,834
  • 4
  • 24
  • 30
  • I don't know much about webapp2, but I've been using Flask for a few months and I love it. I found flask plugins that really helped me out, such as `flask-babel` for multiple language support, and `flask-seasurf` for CSRF support to secure my forms. – ThePloki Nov 08 '16 at 22:49

5 Answers5

137

Disclaimer: I'm the author of tipfy and 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.

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).

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.

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.

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.

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.

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.

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.

Brian Moeskau
  • 20,103
  • 8
  • 71
  • 73
moraes
  • 13,213
  • 7
  • 45
  • 59
  • 10
    Thanks, @moraes! Solid enough. I think such things as blobstore, mail (and probably ProtoRPC) are quite important pieces for that project, and I want to work with them as smoothly as it possible. Also, I think that to mix different frameworks isn't the best idea if you can easily avoid it. Moreover, despite the fact I sympathize with Flask, I'm really impressed with webapp2 and have my hands itching to try it out. Thank you for answer and for webapp2! – Anton Moiseev Jul 22 '11 at 09:52
  • @moraes Is it possible to run webapp2 with Apache? Any links? – 18bytes Aug 05 '11 at 12:21
  • 3
    @Sundar It can run on any WSGI-compliant web server. For Apache there's http://code.google.com/p/modwsgi/ and others. – moraes Aug 06 '11 at 10:55
  • 4
    @moraes: Is this answer outdated now? I can see that GAE SDK supports Flask. Is webapp2 still the better choice? – nish Sep 17 '14 at 16:30
  • 1
    @nish, reference that GAE SDK supports Flask officially? – enkash Mar 19 '15 at 06:35
  • 16
    Just a note, that while this is the legacy accepted answer, webapp2 development is dead. I would say Flask is the way to go. – Jesse Apr 15 '15 at 03:49
  • 1
    @Jesse Forgive ignorance (I had a brief check) but what makes you assert "webapp2 development is dead"? I've seen boilerplate-gae dev *seem* to have made a similar assessment, I'm just not sure what it's based on. Thanx (Yes, I could have missed something vital) – shermy Aug 03 '16 at 02:32
  • 1
    The development of webapp2 has been recently taken by google. (See the webapp2 github page). But... truly it's pretty much dead as no words from google guys on solving issues, roadmap or anything. It's a pitty as I find webapp2 to be more friendly than Flask. – janscas Oct 14 '16 at 12:06
  • How do i insert a debugger line like import ipdb; ipdb.set_trace() in webapp2 like we do in django and flask methods? – Kishan Mehta Oct 26 '16 at 09:50
13

Your question is extremely broad, but there appears to be no big problems using Flask on Google App Engine.

This mailing list thread links to several templates:

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

And here is a tutorial specific to the Flask / App Engine combination:

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.

Community
  • 1
  • 1
agf
  • 171,228
  • 44
  • 289
  • 238
  • 7
    Thanks, @agf. I've seen most of this posts before, but I think I'm more interested in personal experience. I don't think that the question is sooo broad, since I'm not interested in comprehensive discussion or detailed information about a problem, just point me that this and this will be hard or impossible to implement. – Anton Moiseev Jul 21 '11 at 12:28
  • 2
    @Anton, Requesting subjective personal experience is pretty close to the SO guidelines for [questions not to ask](http://stackoverflow.com/faq#dontask). – James Jul 21 '11 at 13:46
  • 9
    @James - Don't agree. I don't ask you about your guesses, assumptions or subjective feelings. I ask about your experience, i.e. about the *facts* that you confidently know. Not obsolete posts, nor problems that other people have faced during heavy customization, just facts. Don't agree - ok, just flag it. – Anton Moiseev Jul 21 '11 at 14:02
3

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.

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.

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.

  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
cat
  • 2,871
  • 1
  • 23
  • 28
  • that's it, OOP support won me. I originally use web.py but webapp2 seems have neat structure without workaround I did on web.py. flask may easy to start, but you need more than that if you plan to make bigger apps – Ahmad Muzakki Jul 05 '16 at 14:21
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

Anup
  • 600
  • 3
  • 9
  • to me, this is not official support, this is only example "you can do it with Flask too"-style. For webapp2, there is still detailed manual with GAE-specific items added here and there. – silpol Jul 01 '15 at 08:38
2

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. For these and other reasons I haven'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.

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.

Niklas Rosencrantz
  • 25,640
  • 75
  • 229
  • 424