Hacker News new | comments | ask | show | jobs | submit login
Flask 0.11 Released (pocoo.org)
368 points by welder on May 29, 2016 | hide | past | web | favorite | 126 comments

One tip if you are about to write your first large (well, larger than 500 lines of code) Flask application: check some example applications for ideas of separation/architecture and some popular modules.

The minimalist nature of Flask, not forcing you to do things in one way and one way only, gives lots of power, but also lots of chances to mess it up and end up with a totally unmaintainable crap. Great power comes with great responsibility. Personally, I quite liked https://github.com/mattupstate/overholt (although some dependencies are out dated!). Also, having some starting point with the boilerplate code already in place helps you to prototype faster, etc.

Speaking of modules, the Flask modules ecosystem is pretty great and familiarizing yourself with it might save plenty of time you'd spend on re-implementing them. Some popular modules that are worth mentioning:

1) Flask-assets https://flask-assets.readthedocs.io/en/latest/ allows to easily integrate processing of the assets (JS minification, SASS compilation, etc) into your development pipeline;

2) Flask-login https://github.com/maxcountryman/flask-login simple users management (roles, authentication, etc.);

3) Flask-SQLAlchemy http://flask-sqlalchemy.pocoo.org/2.1/ simple integration with SQLAlchemy

4) Flask-Script https://flask-script.readthedocs.io/en/latest/ makes it easy to write command line tools which run in the context of Flask application (e.g. some cron jobs).

I also like https://github.com/svenstaro/flamejam/ as a good example of Flask architecture. It's simple and maintainable. I wrote a 4k+ loc app using a similar pattern and it still remains quite easy to handle.

I'm the author of that so if anyone has any questions feel free to shoot. Generally, the project is quite old but I still build flask application in quite the same manner as that. You can see the project running at https://bacongamejam.org

From the release notes, it appears flask.cli may be intended to replace Flask-Script (4): "Added flask and the flask.cli module to start the local debug server through the click CLI system. This is recommended over the old flask.run() method as it works faster and more reliable due to a different design and also replaces Flask-Script."

Yeah, forgot to mention it when writing :)

I've used some example architectures in the past while making a relatively small but very detail-oriented Flask app. I found that testing was a nightmare because my errors were only triggered on runtime. So I ended up having to manually test each code path in order to make sure I didn't have something as simple as a type error in my code. Static analysis helped a bit, but it's not as rigorous as a proper type system. Do you have any advice for this situation? It turned me off of web development in Python almost entirely.

I'm not sure I really understand what you're saying, but in any case, this is a problem with any dynamically typed language, and isn't in any way specific to Flask or even Python. If writing applications without the guarantees of a "proper type system" is painful for you, then Python is probably the wrong language.

That said, you shouldn't have to manually test anything—that's what automated tests are for. With regard to testing Flask applications specifically, there is a guide[0] in the docs that covers everything you need to get started.

[0]: http://flask.pocoo.org/docs/0.11/testing/

This is called "writing tests".

What exactly do you mean by 'errors were only triggered on runtime'?

Are you unit testing?

I wasn't, but I guess this is the only solution. The biggest reason I didn't unit test was that most of my functions were dependent on a significant amount of internal state. I suppose I should have spent more time coming up with mock models to use during unit tests. Also separating functionality would have made things easier.

It sounds like you were doing two things that don't really work well in Python + framework environments in my experience:

1. Depending on internal state: I've always had a harder time working with state, regardless of language. I usually try to structure my code so that most of my business logic is encoded in functions that have inputs and outputs and don't modify any state. Only the toplevel functions modify the state, and they do so by applying database queries or updates that were generated functionally. This also can often drastically simplify or even eliminate your mocks.

2. Not unit testing. Without static types, it's pretty necessary to unit test. Think of it as that you test whether the types are correct by trying to use them in a trivial case. This is a double edged sword: on the one hand, unit tests give you more than static types: a type checker can tell you if the two things you're adding aren't numbers, but it can't tell you that you're adding the wrong numbers. The flipside is that nothing will tell you if you didn't test something, or didn't test it correctly.

I don't know if you'll have opportunity to try it again, but maybe next time try a test-driven development (TDD) approach where you define your function's interface (inputs and outputs) write failing tests that test those inputs and outputs, and then implement to make those tests pass. I don't encourage dogmatic TDD, but it can be a good starting point. Once you get a good feel for what kinds of interfaces are testable and where tests are helpful, you can scale back your testing a bit and test more pragmatically as needed.

This sounds more like an issue with the application design rather than Flask, Python, or even Web development. How easy or hard it is to test software is often a good indicator of the quality of the underlying design - if it is too hard to separate code into testable units and you have to mock loads of things to test for the most basic cases, there's a more fundamental problem somewhere. Of course, there are things that are hard to test, but it shouldn't be the whole application that is hard to test.

Is there a decent Flask bootstrap? I've never been able to get in to Flask because there's so little provide out-of-the-box. I'd be looking for user accounts, admin, form handling, basic crud, sqlite, db schema/migrations.

I'd love a re-write of http://web2py.com that conforms to pythonista expectations.

That's Django. You'd pick Django for those, Flask if you don't need them or want to do them yourself. Werkzeug if you want to do even more yourself, which I have found useful on a couple occasions.

It's the flexibility versus batteries included tradeoff, and I don't think it's a negative that Flask doesn't ship most of that. You could probably somewhat get there with a number of third party additions (gedrap mentioned some) but you might as well use Django if you find yourself needing that stuff baked in.

You appear to be asking to turn Flask into Django, but this gets you most of the way on that specific list: - https://github.com/sloria/cookiecutter-flask

Big thumbs up to cookiecutter-flask. I've built several mid-size Flask apps with it over the past year or so, and I find that it lays a great foundation, for what is in my case a typical setup (e.g. Bootstrap based UI, SQLAlchemy based back-end, simple user accounts). It's well-maintained at the moment, too. When building a new app, first:

  cookiecutter https://github.com/sloria/cookiecutter-flask.git
Then customise all you want.

There's also this skeleton for Google App Engine:


This got me going with Flask. It's not quite everything you asked for but it lays a foundation upon which to build and explore the different features you've listed. And App Engine's free tier provides a nice platform for prototyping and simplifies deployment.

Please don't recommend Flask-Assets, JAC is so much better:


Could you expand on why you think so?

Basically it's django-compressor[1] for Flask. That means automatic detection of static assets from your template files.

Flask-Assets makes you list every static file in a giant config, aka registering your assets in bundles. There is no need for that mess.

[1] https://django-compressor.readthedocs.io/en/latest/

Seconded. I ended up spending several days trying to re-organize my first decent-sized Flask project when I tried to add a different config for testing. On the next project I started with a template that handled the boilerplate bits like app factories and test structure and it went much smoother.

They should really name it Flask 1.0 at this point, as it's a very mature library and lots of people (including me) use it in production settings. In my humble opinion, the 0.11 version number tends to shy people away from the library as it conveys the impression that it's still heavily evolving or not well-tested, which is not the case.

In any case: Congrats :)

They have a 1.0 milestone, so fix all the issues tracking for it and we would get it! I believe the main blocker is updated documentation.


When I decided to learn web dev (coming from a native background), the lack of updates to Flask was more of a concern than the 0.11 version number. Everything I read online said that Flask was rock solid, so getting stuck with an abandoned framework in production was my main concern.

Glad to see Flask's development is back on track, and under formal management!

Flask development has never not been on track, there have been plenty of commits and bug fixes in the last 3 years, theyve just never made a official release until now.

I'm aware, but a web framework going 3 years without a release renders the distinction between "no releases" and "no development" more or less meaningless from an end user's point of view.

Or it means the APIs are stable, and the feature set is sufficiently limited to avoid bloat.

And new releases could be 0.10.2, 0.10.3, ..., with fixes included! And I'm ok with that from user point of view. But Flask package stuck with 0.10.1.

Glad to see 0.11!

The version number is 0.11, which is different from 0.1.

good point, changed it :)

But does it really matter now that Flask is so popular? Probably not :)

This is a big deal. For those unfamiliar with Flask, it's a great library but has been sitting on 0.10 for three years now.

Blog post about it: https://www.palletsprojects.com/blog/flask-011-released/

Why is it a big deal?

It's been sitting for three years because it was just working and given it's minimal nature, there were not many things that should be changed. So not much point to make a release.

For one thing, it means contributors' work sat there for up to three years – not something that would make me want to contribute.

For another, any bugfixes/improvements that had been requested by the community were inaccessible on a release branch, even after they were committed – this sounds extremely frustrating.

Most libraries out there are "just working" – doesn't mean they can't ship improvements, and most do – typically no more irregularly than every 6mo.

Sometimes sth. is done and no immediate improvements are needed. Furthermore, the repo is out there.

>Sometimes sth. is done and no immediate improvements are needed.

That's a very weird thing to say in response to somebody saying, "improvements were needed and made but not released".

> Furthermore, the repo is out there.

Now that's just ridiculous. If somebody wants to not have releases, that's fine. E.g., rbenv plugins just seem to be "pull latest from git". But if somebody is going to have releases, then it's absurd to say: "Hey, if you want this to actually work, don't use the release that all the docs tell you to use; instead build the thing we have explicitly not given to you."

Having releases: good. Not ever having releases: good. Having them but not using them: worst of both worlds.

It's actually pretty easy to install directly from the repo:

    pip install git+https://github.com/pallets/flask.git
However as you mentioned, the documentation really needs to be updated to reflect this. It's frustrating to come across this sort of thing. I've even gone so far as forking packages and releasing latest on PyPi myself (so I can easily pull in the dependency from other packages).

A release is a logical point in a software projects history. Sometimes you have a bunch of stuff on the head waiting a release, but that point is not reached yet. The maturity of the features are not well tested, the API is not fixed, etc. Now IDK this specific case of Flask, but there is no one single release cadence that fits all, nor do the releases need be periodic.

Yes, I think the problem here is that you're opining without understanding the specific case, a case that the rest of us are talking about.

The general discussion of release philosophy could be interesting. If you would like to talk about that, you should start a new topic, or at the very least make it clear you're changing the topic. When you reply to somebody's specific statements with sweeping generalities, as you did here, it looks like contradiction.

Out there is a certain "increasing version number fetishism".

Clearly the only reason people care about this is because of the bigger version number.

All the new features/fixes, contributions finally being released, the increase in development activity, it's all bullshit, people only care about the digits.

Sigh. You're projecting.

Is Pallets the new name for Pocoo?

Pallets is the new umbrella project for all Flask/Werkzeug related projects.

Love Flask. I don't do it anymore for other reasons but flask is what got me started with web frameworks that are minimal but powerful. What I love about flask is that it does not do too much magic like django even though this is not meant to demean django of course. It makes me think and make some choices. Since the core is minimal, you still have to learn a few things to really understand how to put together a decent web app or an API but I really feel that is the strength of flask.

My belief is that when you are learning, start with a minimal framework so that not everything is already done for you a.k.a magic. That will make you think and make some choices. Sure it may be amateur choices in the beginning but you will become a better developer. So if you want to learn python for web, go with Flask.

"What I love about flask is that it does not do too much magic like django"

So having used both, I'd nitpick you on this assertion.

    from flask import request
to get at the individual request objects is sooooo much more magical than

    def my_view(request):

Nevertheless, it's a good framework!

I agree on that. The magical globals are also my biggest problem with flask. Other than that, it's a very solid framework that obviously has had lots of thought go into it.

I think this is just a design choice to avoid confusion between request / session parameters in the view functions versus path parameters.

It's quite nice that you can just do


def my_view(post_id):

never having to register anything and just decorating your functions with these path decorators gets you started really really fast. That's how a flask hello world is just 6 LOC and `python ./my_server.py`.

I just released my first Flask extension called Flask-Ask for developing Amazon Echo skills https://github.com/johnwheeler/flask-ask

Flask is a fantastic, minimal framework, and Mitsuhiko did so much to help new developers integrate into the ecosystem he created. For example, I was able to use his documentation templates https://johnwheeler.org/flask-ask/, and he had multiple versions for small and large projects. When you dive in it's pretty amazing what they've accomplished over the last 5 years.

This is nice to see. I don't use anything but http://bottlepy.org these days because I find the decorator approach to be more elegant, but I do have a few Flask-based tools I adopted, and (for instance) patching them to serialize datetimes was a pain.

Switch to use Bottle for rest API as Flask has dependencies such as Jinja2 that I don't need.

There's also the Falcon framework that claims to be faster and is meant for REST APIs.


Falcon is great for making API's! I've used it on a few production sites. The main downside is the lack of middlewares for common tasks (e.g. jwt decoding) but you gain in other areas such as being able to use class inheritance to abstract out utility stuff in an elegant way.

Take a look at Hug - it's built on Falcon and adds all the API niceties :-) https://github.com/timothycrosley/hug

You don't need middleware to use JWT with Falcon - just import and use a jwt library.

Oh, I already do that. Thought my statement was plain enough.

Are there any decent Bottle bootstrap/boilerplates that provide some of the basics that every project needs like user accounts and admin?

Someone might find this project helpful:


This is a Flask based framework designed with best practices in mind, it comes with many nice preconfigured modules and modern features:

* Gulp integration (sass, minify etc ..)

* Fully configured flask security out of the box (register/login/reset etc ..)

* Cache, Blueprints, Mysql/Nosql, Mail, Background tasks, ORM etc ..

* Debug toolbar

* Command line (Flask script) to help you control your app

* A deployment script that fully configures your server in minutes (Ubuntu):


edit: I'll get this project upgraded to 0.11 to integrate the nice new features, any recommendations/notes are welcome.

Tests ported to py.test. I never got a full understanding on which python unit test lib I should use ..maybe that's a hint.

ps: well thanks for the hints below guys.

I would highly recommend pytest. It's very simple, very pythonic.

Here is for example my Hearthstone simulator, with ~600 pytest-compatible tests: https://github.com/jleclanche/fireplace/tree/master/tests

It's just plain asserts. You run it with `py.test`. Nothing simpler.

Man, I never understood the love for py.test.

People say "it's Pythonic, you just use asserts", but asserts aren't Pythonic. For one, asserts are removed when you run Python with "-O", so, uh, good luck running your test suite in that configuration. Secondly, crawling up the stack to inspect the bytecode to figure out what condition was actually asserted so you can print a nice error... that's the opposite of Pythonic.

Sure, the unittest module in the standard library is a bit Java-ish, but it's much less magic, and I feel like keeping per-test state in a class that gets instantiated multiple times is more Pythonic than having everything be top-level functions.

And of course unittest is in the standard library, which means that most apps and libraries are going to use it, most people are going to be familiar with it, so your app or library will be more approachable to co-workers and/or contributors if it's tested the same way. Heck, a lot of Python frameworks have their own test helpers built on top of unittest (hello, Twisted and Django!) so you don't get to choose anyway.

You could write Python code with three-tab indents, but you should use 4-spaces like everybody else. You could write your own custom packaging and dependency management system, but you should use setuptools like everybody else. You could any number of custom test harnesses, but you should use unittest like everybody else.

> For one, asserts are removed when you run Python with "-O", so, uh, good luck running your test suite in that configuration

Which is not something anyone has ever wanted.

> Sure, the unittest module in the standard library is a bit Java-ish, but it's much less magic, and I feel like keeping per-test state in a class that gets instantiated multiple times is more Pythonic than having everything be top-level functions.

It's really really unpythonic. It looks horrible and leads to messy tests. With pytest you get dependency injection via fixtures which cuts down on so much repetitive initialisation code.

We've got both kinds of tests in our codebase, and the pytest ones are a lot nicer to write and refactor.

So unpythonic that it even uses camelcase.

"Unpythonic" must be something positive. Whenever someone uses that word, I like the code or the application in question.

"Pythonic" seems to mean using magic until an application works in 99% of the cases, satisfies some superficial criteria of readability to those intimately familiar with it and is utterly un-debuggable for those who aren't.

> Whenever someone uses that word, I like the code or the application in question.

Then either they are not describing something unpythonic or you can't visualize how better the code would look if it was pythonic.

> "Pythonic" seems to mean using magic until an application works in 99% of the cases, satisfies some superficial criteria of readability to those intimately familiar with it and is utterly un-debuggable for those who aren't.

Not at all, it's usually exactly the opposite. Open a python shell and type "import this", if Python code satisfies a large enough number of those then it's Pythonic.

The first six pretty much sum it up:

> Beautiful is better than ugly.

> Explicit is better than implicit.

> Simple is better than complex.

> Complex is better than complicated.

> Flat is better than nested.

> Sparse is better than dense.

Words to live by. They all help improve debugging and readability.

Hardly anyone writes code like that in the Python world. It's all about features and gross hacks.

A long time ago, people would have made the exact same arguments about the `requests` library, which is today considered one of the highest quality third party libraries in Python ({{cn}}).

In fact, a lot of the arguments still apply. "urllib3 is in the stdlib, why use requests?". I can get behind that argument in specific cases, too - I have a library which uses urllib3 because it only ever needs to GET from a couple of URLs and introducing an extra dependency just for that is a hassle.

But here's the thing about tests. You want them to be clear, you want them to be easy, painless and even fun to write. pytest achieves that. unittest doesn't. If you're serious about testing, unittest will harm your project.

PS: https://leclan.ch/tabs/

> run Python with "-O"

no one ever does this

Yes Pytest is black magic(I tried and failed to understand it for my own dark purposes). But it lets you get context without violating repeating yourself over and over.

You should repeat yourself in your tests. See DAMP vs DRY [1]. Also that repetition is valuable feedback that you may have a design problem, that something about your object hierarchy is overly-complex, for example. If you hide it, you're just sweeping the problem under the rug.

[1] http://stackoverflow.com/a/11837973

> For one, asserts are removed when you run Python with "-O", so, uh, good luck running your test suite in that configuration.

That's almost entirely all python -O actually does. The only other thing it does is set __debug__ to 0. There's essentially no real value in running code with the -O flag.

Nice sample of tests! I also love pytest, but one of the best things IMO is fixtures, which your tests don't seem to use?

For those who don't know fixtures are a type of dependency injection. You just make a function (e.g game) in a file called conftest.py, and wrap it with a '@pytest.fixture'. Then any tests you write that have an argument named 'game' will have the result of the 'game' function passed as a value.

So 'game' could return 'prepare_game()', and other fixtures can do the same with their arguments to build more complex fixtures. I find it saves a load of initialization code being repeated.

Fixtures are considered an anti-pattern by many as they over-DRY [0] your tests and obscure them by introducing 'Mystery Guests' [1].

[0] http://stackoverflow.com/a/11837973

[1] https://robots.thoughtbot.com/lets-not#will-our-mystery-gues...

Yeah, I don't actually make deep use of pytest functionality. The whole thing used to be runnable without pytest for ease of use (with a __main__ block finding and running all test() functions).

I should definitely use fixtures - been meaning to! It's why I love pytest, you don't need to go deep into it to make a high quality test suite.

Please don't move to fixtures, your tests are great as-is (thanks for sharing). See my comment above!

I agree with it and hold the same view, which is why I haven't moved to them yet.

My plan was to get rid of the "game = prepare_game(...)" line that's present on every single test, and have the game be passed as an argument to the tests which AIUI pytest supports.

Best testing library I've used yet is https://github.com/HypothesisWorks/hypothesis-python. YMMV, of course, but I've always wanted a little more smarts than py.test...

Hypothesis is not a test runner, it's a test generator.

Both are best of breed, and complementary, IMHO.

I'm always impressed with the bugs Hypothesis can find :D Test generators are valuable things, well worth using in combination with a good test suite.

Hypothesis isn't a testing framework, it generates data for your testing framework to test. I use it with unittest and love it. I'm sure it can run equally easily with py.test.

It does. I meant testing as in a process, not as in its specific purpose (and even then it's still ambiguous in English).

Ah, yes, it is pretty great for that. I especially love it for testing algorithm-heavy code, as it's not very well suited to code that's user-interaction-heavy.

I was recently deciding which to use in a small project: unittest, pytest or nose. My default starting point is to prefer the standard library for assumed participation and for longevity, but also to use 3rd party if there's a good reason or a clear consensus.

While looking at nose, I ran across this: https://nose.readthedocs.io/en/latest/

> Note to Users: Nose has been in maintenance mode for the past several years and will likely cease without a new person/team to take over maintainership. New projects should consider using Nose2, py.test, or just plain unittest/unittest2.

That made me not want to investigate nose any further, and I decided I had to just decide and move on, and chose unittest. The suggestion to use unittest in the Note helped make that easier.

Maybe next time I'll use pytest, but I think the issue in the Note will dissuade me from using nose unless it's resolved.

py.test is fantastic, so yes.

IMO, test suites without parameterized test cases are not good.

As such, you need pytest, nose or unittest + ddt|nose-parameterized.

Didn't expect a new flask release because i had the feeling the author moved to rust development. did anything change recently ?

I listened to a Podcast interview with the author. He is spending a lot less time on Python projects than he used to as he does like Rust so spends time on Rust also.


As far as I understood there was a delay in the release process because of documentation missing/outdated and project organization changes, not because the project itself was not moving along.

I think you were mistaken.

I remember him saying that on a podcast. maybe talk python to me.

He is still very active in Python. His recent lektor static CMS is wonderful and written in Python.


I used Flask a few years ago to write a rather large api server (20k lines) for a video sharing app. I learned that they give you a lot of control but it can get messy quickly if you're not careful about properly architecting first.

I ended up getting the Flask Cookbook from O'reilly which helped me understand how to structure a Flask App.

I also recommend Flask-SQLAlchemy as it made writing and manipulating MySQL queries really straightforward.

Who's got two thumbs and has already deployed Flask 0.11 to production? This guy.

I know that version numbers don't necessarily mean anything. Wine took 15 years to get to 1.0, while Chrome and Firefox increment major version numbers every few weeks. But it still seems odd to have a major web framework at 0.11 after six years.

This was supposed to be 1.0 but with such a long time leading up to it i figured it's safer to wait a release to ensure nothing major regressed.

If it is working like it is supposed to, I don't see what the problem is.

No real problem. But I think many can have an subconscious bias that any software at 0.x is unstable. This is how semver[0] treats 0.x releases and it was a common convention long before that.

[0] http://semver.org/

Each project may have a different versioning scheme and that's just fine. Not everyone follows "semver" (although it sounds sensible to me).

Sure. Nothing wrong with whatever (sensible) versioning scheme a project decides to use. But I think version numbers do bias the perceived stability. If I had never heard of Flask and I saw that version 0.11 was released after three years of no new releases, my gut reaction would probably not be overly positive. That said, Flask is indeed a great piece of software :)

I wanted to mention Flask-Diamond in this thread because it can be used to scaffold large applications quickly, sortof like Django.


One reason you might use Flask-Diamond instead of Django is because you might not need everything Django provides, so you want to remove libraries one at a time. Or, perhaps, you want to upgrade libraries one at a time. I've found it's easier to start with a full-blown Flask app, then remove things, rather than starting with a barebones app that I add to.

Are there any plans to integrate the flask-failsafe functionality into flask proper so that flask reloads automatically after a syntax error is corrected and the file saved?

I believe the Flask development server does that already?

No, the dev server can only handle runtime exceptions

I love flask. web.py used to be my "go-to". But as its development has not been as active, I moved over to Flask for the community.

When I know I need an admin and lots of built in items out of the box, I choose Django.

But a quick prototype, always start with Flask.

Are there any high traffic web pages using Flask? I'm interested but when I look at job listings it's really rare I see anything for flask compared to React/Angular/RoR.

If I was a python dev it seems like it might be worth learning but since I'm a web dev and already know a few frameworks I'm struggling to find a reason to teach my self flask.

Does Flask have any advantage over something like Angular?

Flask is a server-side framework, so it’s not directly comparable to front-end frameworks like React or Angular. It plays a similar role to Rails in Ruby, Django in Python or Symfony in PHP, though it’s further towards the lightweight/flexible end of the spectrum than any of those.

I don’t know what you’d consider high traffic, but we have used and continue to use Flask in production for a variety of systems. Those include:

- providing the back ends for relatively large and complicated single-page applications;

- implementing more traditional web sites, with very little JS on the front end, which use Flask to do almost all of the routing and rendering; and

- implementing dedicated HTTP-based APIs for integration with third party services.

Flask is an excellent tool, and that is not a description I use for very much in the software world. It provides widely useful functionality, it has a tidy design and a reliable implementation, it’s well documented, and it imposes few overheads or unnecessary dependencies. If you’re purely a front-end dev then that functionality isn’t what you need and neither is Flask. If you’re interested in the back end as well, you could do a lot worse than to learn Flask.

Flask would be more comparable to RoR than to Angular, since it is principally for backend work. (You can do server-side-rendered front-end stuff with it, with templates, but I choose not to -- currently working with Flask for my backend API, React for frontend).

There are two main features of Flask for me, over something like RoR: it's Python (my preference over Ruby); and it's a very light framework with a ton of modules, compared to my perception that RoR is pretty big and heavy and opinionated.

YMV, I only do this stuff in my evenings so I'm not terribly familiar with it all.

Sinatra has always seemed more like the ruby equivalent of Flask, but I only have a small (and by now, dated) experience of ruby web dev

My Ruby developer friend agrees with you, so I think you're accurate.

You're comparing apples to oranges here. Flask is a server-side framework and doesn't care one whit about what you put on top - it just serves up requests.

We deploy a heavily used REST API that at the top level, is using Flask to capture/proxy/marshal the request and response. We decided to use it over Django simply because we did not need a large set of the Django features.

> I'm interested but when I look at job listings it's really rare I see anything for flask compared to [...] RoR.

That's because Flask is simple. You advertise RoR when you want somebody who doesn't need to spend a lot of time learning Rails. But nobody needs to spend a lot of time learning Flask.

That's also a drawback of Flask, in that you have to build or add more to get the same higher-level expressiveness of something like Rails. But if what the project needs is a relatively low-level web framework, it's a fine, easy-to-learn choice.

Reddit uses Flask for parts of the site.

Uber uses Flask & Nginx for part of their site.

The 2012 Obama campaign team (who really shook up the use of internet & tech in campaigning) used Flask too.

Mailgun uses Flask for their API (reported). Stack is verified here, but no details given: http://stackshare.io/mailgun/mailgun

Flask = backend

Angular = Front end

Bizarre you are comparing them. Suggests you have not used either.

I have no idea where you are looking for jobs but where I am demand for Flask and Django are booming and there is a shortage of them.

Not sure what kind of traffic they get, but httpbin.org uses it. Also this one site named Pinterest.

I am sorry, but it seems that Pinterest is written using Django.


That page does not support the statement that they moved off Django to Flask.

It further links to this post:


> They started with Django but moved out of Django and currently use 'home grown framework on top of Flask'.

But it supports that they do use Flask.

> Presently, the API does over 12 billion requests per day, all in Flask.

Wow, that is 138kqps. Not something that would strike me as your typical Python workload.

There are lots of those lying around.

I don't know if it still is, but when I was at Mozilla the service that every instance of Firefox around the world hits to do the version/extension-compatibility checks was backed by Django, and was at something like 15k req/s served. Firefox has gained some market share in the four-ish years since I got that number, so probably larger now.

Whacking great big CDNs in front of your infra will do that.

What exactly a CDN can do to increase the qps throughput of your backend? I thought it's used to reduce it...

IIRC Twilio use Flask, and contributed the flask-restful library [1]

[1] https://github.com/flask-restful/flask-restful

Flask is a server-side framework, as others have mentioned.

You should be comparing it to micro web frameworks like Nodejs' Express, Ruby's Sinatra, PHP's Slim, Java's Spark, etc.

moving too slow...

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact