
Flask 1.0 Released - JonoBB
https://www.palletsprojects.com/blog/flask-1-0-released/
======
nickjj
Flask has a stigma for not being that good when building larger apps, but
honestly Flask scales really well for that type of use case (coming from a
development / maintenance point of view).

I have some pretty large Flask apps with dozens of top level dependencies and
models spanning across many thousands of lines of code. Even if I don't touch
the code base for a few months, it's easy to jump back into it.

I'm also a huge fan of Rails, but truthfully I find Flask apps to be easier to
reason about and hack on once they grow to a decent size, simply because
Blueprints make it really straight forward and intuitive to modularize your
application without increasing the complexity of everything by using micro-
services.

If anyone wants to jump into Flask and start building real world apps, you may
want to check out
[https://buildasaasappwithflask.com/](https://buildasaasappwithflask.com/).
It's a full blown course where we build a SAAS application using Flask and
Docker. I recently added a free RESTful API bonus section to the course and
now that Flask 1.0 out, I'll be adding another free update which will cover
updating all of the packages in the main app. Just going to wait for the dust
to settle on the 1.0 release first.

~~~
abhishekjha
My employer made me switch from Flask to Django providing non-scalability
reason. I asked around on a few online forums and they told me that flask has
no such issues. There was an article where somebody from DISQUS explained how
they were able to use flask in production without much hassel and there's no
reason to switch to django. My employer told me to not use flask as it is not
production grade. The problem was to implement a few web APIs. I switched,
reluctantly. I am still not convinced though, given that I have very recently
started using Flask/Django, it may come to me at a later time.

~~~
scrollaway
I've been developing with Django since the 0.90 days and, to be honest, I've
seen a lot of scalability issues with Django itself once you get big enough.

Those issues all relate to how Django is an all-in-one solution with a lot of
modules, which you start dropping one by one as you use different solutions.

For example, Django's cache layer is great, but as you scale you'll want to
use Redis clients directly rather than the memcached abstraction.

The ORM is fantastic (and much more intuitive than SQLAlchemy). But as you
scale, you'll want to use Postgres' more powerful features without worrying
about compatibility with MySQL / SQLite. (Django has made progress in that
area with contrib.postgres, but it's still only scratching the surface)

Forms? Templates? Staticfiles? If you're using a JS (Webpack and the like)
frontend, forget about this stuff. You're better off not serving the frontend
with Django at all, it'll only cause more trouble than is worth.

URL routing... again, nowadays even that is done in Javascript. And doing it
in two places at the same time is a pain. Long term, you might drop that too.

What's left? The model layer, and the admin that accompanies it. I wouldn't
trade the Django admin for the world but it also has a lot of scalability
issues and although it's very declaratively customizable, it's much harder to
customize specific models.

The auth layer is also probably something you'll keep for a long time, but
it's littered with things you will probably not use such as the whole
groups/permissions system, or the adminlogs auditing system (which is super
cool but the API is very hard to use outside the Admin).

The problem with Flask is it's missing in the "what's left" parts. And if you
use Flask, you're missing out on the entire Django ecosystem of apps that make
heavy use of the model layer.

But you dear reader statistically will most likely not hit any of these
scalability issues (aside from the frontend ones). So don't feel bad picking
Django, it's an excellent framework regardless.

~~~
oneweekwonder
> ORM is fantastic (and much more intuitive than SQLAlchemy)

Any articles or blog posts you can recommend to give some examples or
comparison?

> entire Django ecosystem of apps that make heavy use of the model layer.

Exactly why I don't want to use the django system. I'm happy with the python
ecosystem and have yet to find a django only module where no other alternative
exist.

Its not that django is a bad web framework; on the contrary, to be honest. I'm
just already invested in other modules that django decided to re-invent/design
to fit their needs better.

~~~
scrollaway
> _Any articles or blog posts you can recommend to give some examples or
> comparison?_

Not really sorry, it's all personal experience.

> _I 'm happy with the python ecosystem and have yet to find a django only
> module where no other alternative exist._

What about all the cases where you need support from database schemas? For
example let's say you want to have access to Stripe subscriptions from Python
and cache them to your database, you'll need something like dj-stripe. There's
nothing "in Python" other than an API client because the Python stdlib doesn't
have a model ORM.

~~~
oneweekwonder
> For example let's say you want to have access to Stripe subscriptions from
> Python

I will use the official stripe flask checkout example[0].

> and cache them to your database, you'll need something like dj-stripe.
> There's nothing "in Python" other than an API client because the Python
> stdlib doesn't have a model ORM.

With their OpenAPI definitions[1] to create the needed sqla model boilerplate,
which creates the needed pgsql tables. For change log of my models it is kept
in my py model files and xml with sql diff using a cheat where I implemented a
Liquibase python wrapper[3].

I'm lucky where I work in a not to enterprise env so self-rolled solutions is
sometimes acceptable and we try to keep it sane.

[0]:
[https://stripe.com/docs/checkout/flask](https://stripe.com/docs/checkout/flask)

[1]: [https://github.com/stripe/openapi](https://github.com/stripe/openapi)

[3]: [https://github.com/Morabaraba/python-
liquibase](https://github.com/Morabaraba/python-liquibase)

~~~
scrollaway
> _I will use the official stripe flask checkout example[0]. [...] to create
> the needed sqla model boilerplate, which creates the needed pgsql tables_

Ok, so let's say someone else wants to apply this pattern (it's extremely
common after all). Should they do the same thing as you did?

Should the next guy as well? Where does it stop? At some point, you write a
library right?

Well that library will end up containing the ORM models. So your choice ends
up being between "I will roll my own models" (whether they're autogen'd from
openapi or not doesn't matter) and "I will use someone else's models". You're
back at exactly the same point as earlier, none of this actually achieved
anything, other than give you extra work.

The point I was trying to originally make is that saying you'll do it "in pure
Python" instead of "in Django" doesn't actually _work_. If by "Python" you
mean "SQLAlchemy" that makes more sense.

At the end of the day, I wish the Django ORM were ripped out of Django so we
could have libraries that depend on Django's ORM without them depending on the
entire Django stack. There's also a lot of demand for the other side of this,
which is having Django's ORM be replaceable by SQLAlchemy. Then you're no
longer talking about "Django vs Flask", but "djangorm vs sqlalchemy".

The final step after this would be to have the Django ORM support SQLAlchemy's
_model declarations_. The Django and SQLA model declarations are already very
similar. _Then_ we live in a world where you can swap out the ORM API at the
application layer, but have libraries that are compatible with both and don't
need to be reimplemented for both Django and SQLAlchemy. (I strongly believe
the distinction between the two model APIs is not useful right now due to how
similar they are)

~~~
oneweekwonder
> Should they do the same thing as you did?

They can, I recommend they look at the swagger-codegen[0] api stub templates.
There clients as well.

[0]: [https://github.com/swagger-api/swagger-
codegen/tree/master/m...](https://github.com/swagger-api/swagger-
codegen/tree/master/modules/swagger-codegen/src/main/resources/flaskConnexion)

> At some point, you write a library right?

Normally a flask-ext forms around a established python library. Yes now we are
back at the tight integration problem, but at-least your knowledge of the py
library will not be lost in another eco-system.

> I wish the Django ORM were ripped out of Django so we could have libraries
> that depend on Django's ORM without them depending on the entire Django
> stack... Django ORM support SQLAlchemy's model declarations... Then we live
> in a world where you can swap out the ORM API at the application layer, but
> have libraries that are compatible with both and don't need to be
> reimplemented for both Django and SQLAlchemy.

Amen Brother!

------
BerislavLopac
I understand that Flask has become popular because it is easy to learn, but my
experience is that as your knowledge progresses it just keeps getting in your
way. I particularly dislike some design choices which look like afterthought
hacks, such as global variables for current request and using abort()
functions instead of raising exceptions directly.

EDIT: To avoid hollow naysaying, here are some alternatives to Flask I find
much better designed:

    
    
        - Tornado Web Framework [0]
        - Falcon [1]
    

[0]
[http://www.tornadoweb.org/en/stable/webframework.html](http://www.tornadoweb.org/en/stable/webframework.html)

[1] [https://falconframework.org/](https://falconframework.org/)

~~~
ckuhl
The real value of Flask is that it makes you appreciate what Django does by
default.

When I first started learning Python / web frameworks, I went with Flask
because it was smaller and "simpler". As my project grew however, I had to
organize it. I was basically imitating what Django gives you by default,
though less cleanly.

~~~
ddorian43
Django has nicely integrated components, but each of flask components are
better (jinja2, sqlalchemy, migrations, etc).

~~~
bobwaycott
Those aren’t Flask components. They just work well with Flask. And Jinja,
SQLAlchemy, and Alembic just happen to be the largest and best of them.

Many of these independent components pale in comparison to their Django
counterparts in glaring ways—they are often a pain to use, with some pretty
questionable internal code choices. They remain used because they are often
the only choice out there, even though their implementations are inferior to
Django’s.

I say this as someone who has used Flask for over 5 years, as well as nearly 5
years of Django.

~~~
ddorian43
They are flask components cause they work well with flask and work bad with
django.

Parts that I mentioned are (or were when I compared) light years ahead
(especially sqlalchemy).

~~~
bobwaycott
I totally agree on SQLAlchemy. It’s very good. As is Alembic.

I feel like most using Flask would consider “Flask components” to be
equivalent to Flask extensions—e.g., Flask-SQLAlchemy vs SQLAlchemy proper.
Maybe it’s a pedantic nitpick, but I’ve never heard anyone refer to SQLAlchemy
as a Flask component in 5+ years, hence my comment about the distinction. But
yes, many of the Flask-compatible Python packages you mentioned are quite a
joy to use.

------
deft
Never even realised it wasn't 1.0, maybe I should pay attention to version
numbers. Changelog looks good!

I've never understood logging in Flask or how to do it in a sane way for a
simple app while using uWSGI, so I'm glad that has some improvements. I don't
remember my exact issues but I couldn't get configuration from a text file to
work and for some reason configuring it in-code wouldn't work either. I don't
understand python's logger in general so I'm sure that's part of the problem.
The changelog is vague on details, but hopefully whatever was modified really
does make things simpler and solves my issues for me.

~~~
avip
My processes always log to stdout. stdout + supervisor + rsyslog = fun and
profit.

You can also log directly to rsyslog with python logger.

~~~
abhishekjha
I have been logging to stdout mostly. Never used/heard of supervisor or
rsyslog. What are their use cases?

------
metalliqaz
Flask is an interesting project. Created by a true Python master only to be
nearly abandoned, and yet it remained so popular it was later revived by a new
group without a major fork. How often does THAT happen?

The post describes it as "stable for a long time" :)

~~~
Siecje
It wasn't abandoned it just doesn't need very many updates anymore.

Also there was no new group this is the official Flask repo.

------
memonkey
Love Flask. It is my favorite back-end framework and has fit all of my needs.
Getting a server up and running with Flask is incredibly simple and if anybody
hasn't played with it yet, I highly recommend it.

~~~
GrandNewbien
It's all fun in games until the project you just started yesterday already
needs an, albeit simple, upgrade.

------
jxub
This is epic. In theory now from V1 onwards it should be easier to convince
people at big serious corps to use Flask as it cuts down a lot of Django bloat
especially for smaller applications, microservices and other nimble backends.

~~~
deft
Hopefully! There's a bad attitude I've noticed about Flask, people don't take
it seriously and treat it like a learning tool or a library for quick and
dirty hack projects. All because it's simple to learn and free of bullshit and
Just Works™. Should lead to the opposite attitude, but nope. People apparently
enjoy extra complexity.

~~~
weberc2
I think a lot of criticism is valid. Flask has a lot of bizarre conventions
which don't scale well, like stuffing all shared resources into the global
context or app-level dicts and using `@route()` decorators all over, for
example. And I'm not sure what the benefit is, except that clever feeling one
gets when they use decorators or other seemingly magical features
unnecessarily and later need to workaround the tight coupling.

~~~
mixmastamyk
Decorators improve dev speed. No need to be constantly switching back and
forth between views and urls.py.

Still, sometimes nice to see all in one place.

~~~
scaryclam
They only improve speed from an initial "get it working" point of view. That's
part of the reason flask is rarely taken seriously as a production solution.
Not having natural separation between views and urls is a real PITA for anyone
trying to create a long term solution or larger project. For what it's worth,
I also hate the argument that bad design increases Dev speed. That's only true
until you need find something later, then you have to hunt around instead of
having one place to look, wiping out any initial gains. It's false economy.

~~~
mixmastamyk
True in a very large project, false on the rest. Congrats on your one-true-way
argument. ;)

~~~
weberc2
I'm a professional Python dev, I have no reason to believe that decorators
save any time for any size of project. They're harder to reason about for
developers of all experience levels and their is no obvious advantage--some
argue that the syntax is more pleasant, but I don't perceive an increase in
readability; certainly not one that makes up for the increased cognitive
burden. The following is super straightforward, testable, and it doesn't
depend on globals for shared resources or request state:

    
    
        def hello_handler(r: Request) -> Response:
            return Response.ok("Hello!")
    
        def goodbye_handler(r: Request) -> Response:
            return Response.ok("Goodbye!")
    
        if __name__ == "__main__":
            router = Router("/")
            router.register_route("/hello/", "GET", hello_handler)
            router.register_route("/goodbye/", "GET", goodbye_handler)

~~~
mixmastamyk
I was thinking more of the fact the are paired with the view. To be honest
never gave the fact they are decorators much thought.

------
mixmastamyk
Love Flask in theory. My biggest complaint was trying to do user management
with it. Flask-Security was good, but the developer skipped town a few years
ago. Did they come back? :D

Basically you are left to your own devices, which sounds great, but user+auth
is pretty fundamental to be left to a random absentee third-party in my
opinion.

~~~
diminoten
Try farming out the auth to a middleware. That's what I do and it works really
well.

~~~
mixmastamyk
Does it interface with sqlalchemy, onboarding, email, etc?

~~~
diminoten
Your auth middleware can attach a user object to environ that your downstream
apps could reference.

Whatever else you do (email, onboarding, sqlalchemy) you can do downstream, or
directly in the (or a different ) middleware if you want.

------
ryanar
Awesome news! I am sad to see you leave Zero Versioning though. [1]

[1] [https://0ver.org/#notable-zerover-projects](https://0ver.org/#notable-
zerover-projects)

~~~
Volt
Why is Zero Versioning a good idea?

~~~
dfinninger
I believe the parent comment and ZeroVer are tongue-in-cheek. Reading through
the site brings Poe's Law to mind.

~~~
mhashemi
Was it the literal link to
[https://en.wikipedia.org/wiki/Poe%27s_law](https://en.wikipedia.org/wiki/Poe%27s_law)
on [https://0ver.org/about.html](https://0ver.org/about.html) ? :P

Countless people are already using 0ver, and always will. In other words,
0ver.org is descriptive, not prescriptive.

------
dsc_
We (a big newspaper - 5k-10k visitors at any time) run on Flask. Quite a big
application.

It was the biggest reason why I choose this job, as many python shops seem to
run Django which I'm not a fan of.

------
akmittal
Flash was the first backend framework I really understood. It was very easy to
get started with. I no longer use it but it made it so easy to learn web
development.

------
aphextron
Is there a good "zero config" application server for Flask that is considered
standard now? I absolutely loved building an app with Flask but I rememeber
deployment being a pain.

~~~
cuchoi
PythonAnywhere isn't zero config, but pretty easy in my experience:
[https://help.pythonanywhere.com/pages/Flask/](https://help.pythonanywhere.com/pages/Flask/)

------
oca159
I don't understand why use Flask instead of Django, I usually work with a lot
of crud systems, I think that Django is the best option to do it. I think that
Django is better because it has an autogenerated admin site and this is really
helpful when you work with the customers, they can easily populate the
database while you work in the logic

~~~
cuchoi
Django is pretty good at that! I think we usually try to compare frameworks to
an extreme when partly it boils down to the type problem and the developer
preferences.

------
adjkant
Flask is an absolutely amazing experience for small-mid sized projects. You
have to hand roll and pull in things for bigger projects, but I think it's
great when you want "just what I need and nothing extra".

I'd be curious to see some sort of flask "bundles" that would allow it to make
more sense for large-scale projects.

------
ksahin
[https://github.com/hack4impact/flask-
base](https://github.com/hack4impact/flask-base) is an incredible boilerplate
for Flask, I use it for every projects ! Lots of basic web stuff included,
user management, redis queue for asynchronous tasks etc..

~~~
fiedzia
Every non-trivial Flask projects aims to become Django.

~~~
scaryclam
This has been my observation as well. It also seems that a lot of teams that
do that are kind of snooty about Django, not realising that they've
essentially invented a worse version of it.

------
_eht
I can't speak to large apps, but it sure is nice for rapid prototypes. I
wanted to play with the Twilio API the other day, and it make things really
easy: [https://github.com/e-ht/89memes](https://github.com/e-ht/89memes)

------
abhishekjha
This[0] is a pretty good starting point. The organisation of modules as well
as the swagger documentation provides a pretty good insight about what can be
done in flask. Out of curiosity, is it possible to change a few tags in the
swagger doc that one gets to see in the browser? I would like to take a few
tags out. I looked it up for spring and the process was pretty daunting.

[0][http://michal.karzynski.pl/blog/2016/06/19/building-
beautifu...](http://michal.karzynski.pl/blog/2016/06/19/building-beautiful-
restful-apis-using-flask-swagger-ui-flask-restplus/)

------
luord
Awesome news. Time to update my project templates.

------
chasedehan
wow, lot of Flask haters here.

I personally love it and have used it for a ton of smaller projects. For
example, I just deployed this a couple days ago:
[http://dadjoke.info](http://dadjoke.info)

~~~
tudelo
FYI your home page refers to "DadJokeJunkie.com promises not to spam you or
share your number and you can opt out at any time." but that is not your site
:P

~~~
chasedehan
Yeah, I know. Was having problems with the domain and bought the .info to just
make it work. Once I have a couple minutes, I'll make it work with the other

------
cup-of-tea
People always talk about scaling large apps with Flask or Django, but I think
that misses the point. If your app gets large enough it will inevitably start
to go its own way. The point of these libraries is that lets you do a hell of
a lot really quickly.

I'm someone who quit web programming in around 2008 while IE6 was still a
thing. I used to write PHP without a framework. As someone just getting back
into it, Django and Flask or downright magical. I can do so much so quickly
that would have taken days to do before. With Flask-RESTful you can turn some
code into a microservice in about 10 minutes.

For me, this is what makes these libraries great, not that they will fit every
need of every app ever.

