Hacking Flask: A Success Story(blog.sendhub.com)
blog.sendhub.com
Hacking Flask: A Success Story
http://blog.sendhub.com/post/48832423565/hacking-flask-a-success-story
9 comments
You're right: it is meant to be tinkered with! Reading this [0] was one of the most encouraging pieces of documentation I've read in a long time:
"Read the source. Flask’s code is written to be read; it’s documentation published so you can use its internal APIs. [...] The API docs are full of available overrides, hook points, and Signals. [...] The Flask class has many methods designed for subclassing [...] You can introduce WSGI middleware to wrap your Flask instances and introduce fixes and changes at the layer between your Flask application and your HTTP server [...] If none of the above options work, fork Flask."
Even from just a software architecture perspective, I'm incredibly impressed with what Armin Ronacher has done with this project.
[0] http://flask.pocoo.org/docs/becomingbig/
"Read the source. Flask’s code is written to be read; it’s documentation published so you can use its internal APIs. [...] The API docs are full of available overrides, hook points, and Signals. [...] The Flask class has many methods designed for subclassing [...] You can introduce WSGI middleware to wrap your Flask instances and introduce fixes and changes at the layer between your Flask application and your HTTP server [...] If none of the above options work, fork Flask."
Even from just a software architecture perspective, I'm incredibly impressed with what Armin Ronacher has done with this project.
[0] http://flask.pocoo.org/docs/becomingbig/
Great post, thanks! I've also been working with Flask and have found it extremely flexible.
Does SendHub use Flask in any sort of production environment? It's always been touted as a great small framework, but rarely (if ever) do we hear about sites using it in some sort of large-scale effort.
Does SendHub use Flask in any sort of production environment? It's always been touted as a great small framework, but rarely (if ever) do we hear about sites using it in some sort of large-scale effort.
At present, SendHub's public-facing API is pretty much all Django, but we've already ported several vital backend services off to their own Flask applications.
With regard to large-scale projects, the usage at SendHub is substantial. I am also aware of flask-restful[1], which looks like it could be useful for building out a more complex API service.
To be completely honest with you, I would gladly take Flask over Django/TastyPie or any of the other numerous Python frameworks I've worked with. For me it brings back the pleasure to coding in Python -- even if this is a case of redefining methods because Flask and Werkzeug are such thin layers that there is simply no configuration! There is certainly nothing comparable to the awesome power of Jetty on the JVM in Python.
[1] https://github.com/twilio/flask-restful
With regard to large-scale projects, the usage at SendHub is substantial. I am also aware of flask-restful[1], which looks like it could be useful for building out a more complex API service.
To be completely honest with you, I would gladly take Flask over Django/TastyPie or any of the other numerous Python frameworks I've worked with. For me it brings back the pleasure to coding in Python -- even if this is a case of redefining methods because Flask and Werkzeug are such thin layers that there is simply no configuration! There is certainly nothing comparable to the awesome power of Jetty on the JVM in Python.
[1] https://github.com/twilio/flask-restful
I would gladly take Flask over Django/TastyPie
Could you explain the benefits or difference for you?
Personally, I enjoyed using Tastypie, and when things weren't clear, its code was a pleasure to read and made things easier to understand or work out how to solve. Perhaps similar to your experience with the Flask code.
I imagine a thinner framework is cleaner in many ways, but then with a more robust framework you get stuff out of the box. In this particular case, getting the request time (+ if you want, sql time etc) is relatively easy and there are a few middleware options to do it in Django.
I've seen an interesting talk[1] by Yehuda Katz: "why rails is hard". One of the key points, if I can somehow paraphrase, is that with a bigger framework like rails, you get a lot more out of the box for the 'price' of it being heavier... He's comparing rails to node and sinatra, but the same might apply to the comparison between django/tastypie and flask I suppose.
Finally, I don't know about flask, but another important point in Yehuda's talk was that some of those things implemented for you, you might not even know that you need. This is true particularly for security, where you probably don't have to think about whether XSS/CSRF protection is implemented etc, you just want things to be secure by default and it's not a feature you even think about...
I am not saying flask doesn't have those (I don't know), just that in general that's usually the trade-off between heavier and lighter frameworks. (I think) I know the downsides, I'm curious to know about the upsides too.
[1]http://www.youtube.com/watch?v=2Ex8EEv-WPs
Could you explain the benefits or difference for you?
Personally, I enjoyed using Tastypie, and when things weren't clear, its code was a pleasure to read and made things easier to understand or work out how to solve. Perhaps similar to your experience with the Flask code.
I imagine a thinner framework is cleaner in many ways, but then with a more robust framework you get stuff out of the box. In this particular case, getting the request time (+ if you want, sql time etc) is relatively easy and there are a few middleware options to do it in Django.
I've seen an interesting talk[1] by Yehuda Katz: "why rails is hard". One of the key points, if I can somehow paraphrase, is that with a bigger framework like rails, you get a lot more out of the box for the 'price' of it being heavier... He's comparing rails to node and sinatra, but the same might apply to the comparison between django/tastypie and flask I suppose.
Finally, I don't know about flask, but another important point in Yehuda's talk was that some of those things implemented for you, you might not even know that you need. This is true particularly for security, where you probably don't have to think about whether XSS/CSRF protection is implemented etc, you just want things to be secure by default and it's not a feature you even think about...
I am not saying flask doesn't have those (I don't know), just that in general that's usually the trade-off between heavier and lighter frameworks. (I think) I know the downsides, I'm curious to know about the upsides too.
[1]http://www.youtube.com/watch?v=2Ex8EEv-WPs
A form handling library Flask-WTF had CSRF handling enabled by default.
http://pythonhosted.org/Flask-WTF/
This page outlines some further security considerations:
http://flask.pocoo.org/docs/security/
http://pythonhosted.org/Flask-WTF/
This page outlines some further security considerations:
http://flask.pocoo.org/docs/security/
There's Flask-SeaSurf which adds csrf to any POST or PUT request.
[1] Would you care to elaborate how Flask helps in writing backend services? It seems to be that most benefits of Flask are frontend related...
Do you talk over HTTP to backend services, encoding it via JSON?
[2] I didn't understand what you mean't about Jetty here (I like its philosophy too :)
Do you talk over HTTP to backend services, encoding it via JSON?
[2] I didn't understand what you mean't about Jetty here (I like its philosophy too :)
#1: At SendHub we strive to always eat our own dog food, which translates to 99% of the data being accessed via JSON APIs.
#2: Jetty provides tons of configuration options, whereas Flask has very little in the way of configuration other than swapping out components.
#2: Jetty provides tons of configuration options, whereas Flask has very little in the way of configuration other than swapping out components.
Out of curiosity, how do you inject your own request_handler if you are running behind something like uwsgi/nginx where you only specify the wsgi container and don't ever call run yourself? It appears the request_handler is only passed on through to werkzeug via run(kwargs).
You don't, he just hacked the development server Flask uses, you shouldn't use it in production anyway.
The better and more general approach would be using a WSGI middleware.
The better and more general approach would be using a WSGI middleware.
Shouldn't the super call be:
super(MyFancyRequestHandler, self).send_response(code, message=message)
super(MyFancyRequestHandler, self).send_response(code, message=None)
Spot the python3 syntax:
super(ClassYouObviouslyMean, self).send_response(*a, **kw)
super().send_response(*a, **kw)
def f(x=default_value, y=None): pass
def f(x:arbitrary_object=default_value,
y:this_doesnt_equal_None_y_does=None) -> more_wtf: ...Nice catch, thank you! I've updated the article and gist with your correction.
The one thing that has me worried about using Flask is python 3 support; the last I heard, Armin had moved on and it wasn't looking like he would be putting much work into Flask. Does anyone know if there is ongoing work to bring Flask to python 3?
I've been playing around with Bottle, largely because I want a python 3 web framework, but I would much rather build with Flask.
I've been playing around with Bottle, largely because I want a python 3 web framework, but I would much rather build with Flask.
sort of answering my own question from deeper in the comments,
https://twitter.com/mitsuhiko/status/323177177367601152
looks like Armin is gearing up to take care of business!
https://twitter.com/mitsuhiko/status/323177177367601152
looks like Armin is gearing up to take care of business!
Have you considered wheezy.web?
Even if Flask was crap... it would be so well documented, I could use it.
I'm trying learn Tornado and every time I'm caught thinking: If only their docs were like pocoo..
I'm trying learn Tornado and every time I'm caught thinking: If only their docs were like pocoo..
I got started because in the Flask docs section, they had a .mobi file to download and read on my Kindle. (They also have PDF, ePub, zipped-html). I wish more projects had such excellent documentation, including a lot of the Flask extensions that I find on github.
FYI Tornado now has PDF and epub downloads available: https://readthedocs.org/projects/tornado/downloads/
Many python projects have PDF docs produced automatically by readthedocs, although they're often not easily discoverable.
Many python projects have PDF docs produced automatically by readthedocs, although they're often not easily discoverable.
Cool thanks for the heads up. Might have to check that out, since I'm still searching for how I'm going to manage my websocket connections to a server....
At the risk of starting a flamewar :), what are some advantages of Flask over Bottle and vice versa? [I started on bottle and never switched]
Straight from the horses mouth:
The big difference is that Flask is based on other technologies such as Werkzeug and Jinja2 that exist for a longer time and it does not try to reinvent things. Bottle on the other hand tries to stick to the one-file approach. I want to merge them but the Bottle developer does not seem to be very happy about the idea of stepping away from the “one file” requirement.
Regarding flexibility: there are no reasons you shouldn't be able to use flask with other template engines if that's what you're after. In fact, things like Flask-Genshi exist: Flask-Genshi and it's incredible easy to use mako with it, even without extension if you want to.
Bias warning: I am the developer of Flask, Werkzeug and Jinja2.
http://stackoverflow.com/questions/4941145/python-flask-vs-b...
In my own experience, both are great, and similar. For a simple REST API bottle has an added advantage of being a single file which is nice to just include with all of your other code rather than having to install anything. Flask, however, is my go-to framework. I used it extensively at a previous job and still do today with my current employer (and the app is pretty substantial). Flask also has a lot of extension support now. A pip freeze | grep Flask yields the following for one project.
The big difference is that Flask is based on other technologies such as Werkzeug and Jinja2 that exist for a longer time and it does not try to reinvent things. Bottle on the other hand tries to stick to the one-file approach. I want to merge them but the Bottle developer does not seem to be very happy about the idea of stepping away from the “one file” requirement.
Regarding flexibility: there are no reasons you shouldn't be able to use flask with other template engines if that's what you're after. In fact, things like Flask-Genshi exist: Flask-Genshi and it's incredible easy to use mako with it, even without extension if you want to.
Bias warning: I am the developer of Flask, Werkzeug and Jinja2.
http://stackoverflow.com/questions/4941145/python-flask-vs-b...
In my own experience, both are great, and similar. For a simple REST API bottle has an added advantage of being a single file which is nice to just include with all of your other code rather than having to install anything. Flask, however, is my go-to framework. I used it extensively at a previous job and still do today with my current employer (and the app is pretty substantial). Flask also has a lot of extension support now. A pip freeze | grep Flask yields the following for one project.
Flask==0.9
Flask-Admin==1.0.5
Flask-Assets==0.8
Flask-Babel==0.8
Flask-Cache==0.10.1
Flask-Classy==0.5.2
Flask-DebugToolbar==0.7.1
Flask-Gravatar==0.3.0
Flask-Login==0.1.3
Flask-Principal==0.3.4
Flask-SQLAlchemy==0.16
Flask-WTF==0.8.2>The big difference is that Flask is based on other technologies such as Werkzeug and Jinja2 that exist for a longer time and it does not try to reinvent things. Bottle on the other hand tries to stick to the one-file approach. I want to merge them but the Bottle developer does not seem to be very happy about the idea of stepping away from the “one file” requirement.
And seeing that Flask still does not support Python 3, while Bottle does, I'm happy with the decision of the Bottle developer.
Not to mention that the "one file" makes deployment very easy.
Plus: Bottle is quite faster than Flask, even if you count the overhead of a DB query:
http://blog.curiasolutions.com/the-great-web-framework-shoot...
And seeing that Flask still does not support Python 3, while Bottle does, I'm happy with the decision of the Bottle developer.
Not to mention that the "one file" makes deployment very easy.
Plus: Bottle is quite faster than Flask, even if you count the overhead of a DB query:
http://blog.curiasolutions.com/the-great-web-framework-shoot...
> Plus: Bottle is quite faster than Flask, even if you count the overhead of a DB query:
If you see bottle being faster than Flask in a real-world benchmark and the difference the problem there are still knobs to turn if you need to. Flask does not optimize at all for Benchmarks and you pay for some overhead out of the box for a better development experience.
If you see bottle being faster than Flask in a real-world benchmark and the difference the problem there are still knobs to turn if you need to. Flask does not optimize at all for Benchmarks and you pay for some overhead out of the box for a better development experience.
A smaller surface for attacks, too. Might be a consideration.
In my mind, there are two main differences. First bottle supports Python 3. Second, Flask is built on Werkzeug, which is a very flexible WSGI toolkit. In practice, I have never used Werkzeug much, except for the excellect stacktrace pages, which let you run the debugger right where you problem failed. I pick bottle for new projects, basically because of the Python 3 support. Fixing unicode is worth quite a lot to me.
FYI, it looks like plans for porting werkzeug / flask to Python 3 may be close at hand. https://twitter.com/mitsuhiko/status/323177177367601152
Yes. Stuff is happening soon, getting prepared for it :)
When I was researching on which framework to replatform to, Flask seemed to have a lot of extensions (http://flask.pocoo.org/extensions/) available for it than bottle (http://bottlepy.org/docs/dev/plugins/index.html) .
Also, Flask the concept of modules/Blueprints for building larger apps. I'm not sure whether Bottle does or not, but the bottle website seems to imply that it's optimized for single file applications.
I used Bottle for a small learning project, though, and found conceptually a lot of things are very similar. We ended up using Flask because it seemed better constructs were in to use it as a foundation for a large code-base, similar to Django, but custom built with legos.
Edit: removed markdown urls
Also, Flask the concept of modules/Blueprints for building larger apps. I'm not sure whether Bottle does or not, but the bottle website seems to imply that it's optimized for single file applications.
I used Bottle for a small learning project, though, and found conceptually a lot of things are very similar. We ended up using Flask because it seemed better constructs were in to use it as a foundation for a large code-base, similar to Django, but custom built with legos.
Edit: removed markdown urls
http://www.slideshare.net/r1chardj0n3s/web-microframework-ba... this might be helpful
(bottle user here too)
(bottle user here too)
So the baserequesthandler serves the same purpose as wsgi middleware but more verbose and front page worthy?
Am I the only person who read the title and thought there was a 0-day exploit on the framework?
The media coopted the term hacking to mean cracking or breaching the security of software or a system.
The good news is that the original meaning of the term hacking/hacker/to hack seems to have regained popularity in recent years.
You probably weren't the only person to think what you did but by reclaiming what is truly ours we can win. Note also that you are reading a site called 'hacker' news.
Personally I make it a rule never to use the term 'hacker' in the media coopted sense.
The good news is that the original meaning of the term hacking/hacker/to hack seems to have regained popularity in recent years.
You probably weren't the only person to think what you did but by reclaiming what is truly ours we can win. Note also that you are reading a site called 'hacker' news.
Personally I make it a rule never to use the term 'hacker' in the media coopted sense.
I understand this 100%, but 'hacking' versus 'hacking something' still feels different to me.
It also seems designed from the ground up to be tinkered with and modified so I'm not worried about having to monkeypatch things weirdly or that my mods will break plugins.
It's one of the few software projects I rave about!