This "transparency" of Flask is exactly what made it my go-to web framework. I can do common things easily, and when it's time to do uncommon things I can figure out what Flask is doing at every level of abstraction.
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!
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.
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.
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.
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.
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).
(or even better, with args and kwargs)? Otherwise it seems that the message is discarded and None is always passed. This is one of the places where python's syntax is awful IMHO. Setting a default value shouldn't be the same as passing a parameter.
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 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.
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....
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.
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.
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:
> 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.
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.
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.
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.
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!