
Discover Flask - rkda
http://discoverflask.com/
======
ryannevius
It's interesting (exciting) to see all of the excitement about Python
frameworks on HN lately. I've used both Flask and Django extensively, and
highly recommend them.

I used to be on the Flask "micro-framework" bandwagon...until I realized that
almost everything I was integrating into Flask was already included in Django
(e.g. a test suite, an ORM, database migrations, authentication, an admin
interface, etc.). Don't get me wrong; I love Flask. It launched me into web
development with Python at a time when Django only confused me. But I just
can't justify using Flask for a big project anymore when Django is just so
much faster to work with (for me). If I need to, I can customize nearly any
part of Django I want, store it as a project template, and use `django-admin
startproject myproject
--template="[https://sometemplate.com/in/a/git/repo.git"](https://sometemplate.com/in/a/git/repo.git")
` to start a new project with it.

~~~
siddhant
Django is cool, and has been my choice for a fair number of projects. Although
recently I had an interesting experience with it when I wanted to use
websockets (yes, I know it's not written for that use case).

It was stunning that most of the solutions out there rely on some sort of a
hack to get it working. I ended up porting over my project to Tornado, because
I need websockets for a lot of the features I'm working on. And it worked out
really well, especially after I combined it with SQLAlchemy and Alembic. 80%
of the feature set right there. And SQLAlchemy is such a fantastic toolkit.

I'm hoping that django channels
([http://channels.readthedocs.org/en/latest/](http://channels.readthedocs.org/en/latest/))
stabilizes soon.

~~~
jkarneges
I prefer to split a server app into a connection management layer and a
backend logic layer. This way the backend can remain stateless which makes for
easier maintenance. I use Django as the backend piece in most of my realtime
apps (for example WebhookInbox) and it works great.

Of course, native support for long-lived connections in Django would be cool,
if only because it would mean the connection management layer could be built
with Django too.

------
level09
Great job. I recommend Flask to everyone who wants a clean and modern
framework that is simple to use and manage/deploy.

I'm also planning to write a series on how to build a simple SAAS with flask,
hope some will find that interesting.

~~~
ergo14
Flask is using globals everywhere, and for very long time did not support
Python 3.x.

~~~
rockyearth
Although most of the methods are globally bound to the current request, Flask
is thread safe and I can't see any problem with it. (except that it encourages
beginners to use globals, which might be process and thread-unsafe).

~~~
veeti
I really don't see any benefit or sense in the Flask way of exposing request
state through imported globals. It makes testing of views unnecessarily
complex: you have to either patch the import or set up the thread local
context in every test. And like you mentioned, it encourages unnecessary
coupling.

It would be so much simpler to just have a request argument passed to each
view.

~~~
Ao7bei3s
But then you have to explicitly pass the context to everything you call.

Dynamic scoping would solve this problem (and similar problems, like
dependency injection), but Python doesn't have that.

Flasks way emulates it as well as possible.

------
whitehat2k9
Great work, but in my opinion using Flask for full-stack, end-to-end web
development is wrong. A microframework should never be used as an end-all-be-
all. By the time you're done you've added god knows how many external
dependencies and bits of homegrown code to support "standard" features such as
authentication, forms, etc. that are part of a proper full-stack (read: not
micro) web framework. In this case, something like Django would be _much_ more
suitable because by the time you've finished this Flask tutorial you've
basically implemented key parts of the Django standard library.

------
volent
I found it very strange that the domain (discoverflask.com) is just a
redirection to the Github repository.

Anyway, great content for Flask beginner. It's a wonderful framework for
anybody wanting to write clean APIs and it's this kind of content that makes
the community awesome.

~~~
hugs
I've done that redirect-to-github thing in the past. Usually, the intention is
that the redirect is intended to be a temporary placeholder until I can create
a "real" site at the domain.

------
Sami_Lehtinen
I've been very happy with Bottle. [http://bottlepy.org](http://bottlepy.org)
Pretty similar, but lighter.

~~~
reustle
Glad to see Bottle is still alive. I contributed to it a tiny bit a few years
back, and it was definitely a fun too. I ended up moving to Flask because the
larger community and wider set of plugins and tutorials.

------
rkda
And here's a link to the Vagrant instance

[https://github.com/apolloclark/discover-flask-
vagrant](https://github.com/apolloclark/discover-flask-vagrant)

~~~
niwox
Great work. I'll definitely look into this one

------
elbigbad
This is great. For anyone interested in learning further, this is basically
considered the Flask bible:

[http://blog.miguelgrinberg.com/post/the-flask-mega-
tutorial-...](http://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-
part-i-hello-world)

------
hanniabu
If the owner of the repo drops by, I'd just like to say thank you for pulling
all this together. Side note, I'm definitely more of a fan of the blog post
tutorials like with the first 2. It's nice to be able to easily skim through
for what you need, the documentation is also nice and condensed like cliff
notes of the actual documentation. I also like how it's accompanied by the
videos too though, so if you're looking for a little more detail you can go
check out the video really quick to see what other side comments or pointers
are made in the vid. Yes one can just look at the documentation, especially
with how great the Flask documentation is, but sometimes it's just easier to
check it these tutorial styled helpers since they have certain objectives and
extra commentary.

------
randomsearch
I've played with a bunch of Python web frameworks and amongst the micro-
frameworks, Flask is the one I've settled on. Larger community, more
integration with other packages.

I've also recently been using Django, and I'd say the biggest advantage of
Flask is simplicity.

When you get to something the scale of Django, there's a whole load of
decisions and culture baked into the approach, and you have to learn that in
order to use it.

For small projects, I'd recommend Flask.

------
mekoka
After reading some comments pinning Flask and Django for "big" projects, I
feel compelled to write my own experience.

Flask is a micro-framework, but it's not a toy framework (anymore). I've used
it professionally for _all_ web related projects big and small for the last 4
years with great success. I wholeheartedly recommend it. It's not for
everybody though, as one can attest by various comments lamenting its
minimalist approach. Things that attract someone like me who likes a certain
degree of control on how my tools are set up and work, may be the same that
repulse someone else more concerned with having everything available in the
kitchen sink.

When I moved to Python for web development Django was the most common
recommendation. I had toyed with it a bit previously and considered settling
for it. Amid the raves though were a few complains that gave me pause, most
coming from experienced Python programmers. A common remark was that as time
went and as they evolved with the framework, it wasn't uncommon to swap parts
out of it for external libraries. SQLAlchemy, WTForms, Jinja2. In some case
basically ending with only the routing module and the admin. Which raised the
question of the relevance of using a full-stack framework not necessarily
designed with interchangeability in mind, if you end up just using it like a
glue mini-framework. Having worked with full-stack frameworks before I
identified with the highlighted pain points and Flask became very attractive.
I picked it up for a first project and never looked back. It's been over 4
years now. It's entirely possible that I'm missing out by not working with
something more like Django, although I doubt it very much.

Flask itself is small, made of bits of the Werkzeug WSGI toolkit and the
Jinja2 template engine. It's simple in concept, simple to set up, and simple
to use, but anyone who's been developing with it for anything more than basic
projects (static sites, microblogs, etc) knows that to do more complicated
stuff than displaying template pages you will need to add some dependencies
(as it should be). You can do it the old-fashion Python way, by simply
importing modules and working with them, or you can install an extension.
There's currently a great variety of extensions, the official list is here
[http://flask.pocoo.org/extensions/](http://flask.pocoo.org/extensions/), with
lots more available from Github and PyPI. Furthermore it's dead simple to make
your own if you're not satisfied with the offering. All of this is probably
the reason why 5+ years after its creation you see a good number of guidelines
on how to work with it for ambitious web projects.

------
0xCMP
I haven't checked the quality, but I love the idea and presentation. This is
an awesome way to approach showing people how to build fullstack websites in
any framework or language to advanced beginner or intermediate programmers.

As someone who procrastinates on their own blog to teach people this topic,
this is going to inspire my direction a lot.

------
icpmacdo
I don't know anything of flask or python really. Is Flask in python 2 or 3? Do
I go learn python 2.7 right now or Python 3? Is stuff broken the the eco
system. Does it make sense moving over from JavaScript for easier backend
CRUD'ish app's? Thanks HN.

~~~
devishard
Python 2.7 will be around for a while due to legacy code, but it's only a
matter of time before Python 3.x is more widely used. Don't invest time
learning skills that will only dwindle in value.

Some stuff is broken in the ecosystem. That's true of all ecosystems. If
you're coming from the JS world it's far, far better. But if you are importing
every 0.x versioned library that vaguely solves a problem close to your
problem, no ecosystem will save you.

Python is a solid choice of language for the back ends of web applications.

~~~
lrem
> Python is a solid choice of language for the back ends of web applications.

With caution advised when it comes to scaling. You might, or might not, pay a
pretty hefty premium in the amount of hardware needed.

~~~
ianamartin
I don't want to come across as a Python zealot here, but in my experience,
Python has almost never been the problem in scaling. Certainly not to the
extent where I would say that it costs a premium in hardware. Though, I
suppose it depends on the application.

My experience has been that Python will give you more than enough rope to hang
yourself with, and lots of apps that are meant to scale have some homegrown
crap of an architecture, or people try to get fancy when they don't need to
and try to write go or scala in Python.

If you have a clear understanding of your data model, Python backends scale
quite well vertically. Run one instance of your app per core you have
available and use IPTables to round robin (or whatever. you can get fancier if
you feel like it) to each app instance. Boom. You are now banging on all 4 or
8 or however many cores your server has without the context switch overhead of
the multiprocessing module and also without the headaches that go along with
the shared memory space of the multithreading libs. Not to mention cleaner,
nicer code.

If you build your product to work well in this way, then scaling horizontally
also becomes a non-issue as far as Python code is concerned. You just put
haproxy in front of multiple machines, set up health checks, and for the vast
majority of use cases, you're done until you need to scale the storage
horizontally. Then you have some serious decisions to make. But that's a
different topic.

But back to my original point: every case where I've seen Python being all
slow has really been an artifact of a crap architecture, or bolting on crap
front end frameworks, or depending too much on an ORM like SQLAlchemy without
really understanding your data and depending on it to do everything for you
instead of thinking rationally about what your data _is_. Or some combination
of all three above.

Yes, I know that there are languages that execute much faster than Python. I
work with C#/.NET/SQL Server almost as much as I use the
Python/Pyramid/PostgreSQL stack. I can write a crappy, slow, messy
architecture on either stack. And in fact, when I was first getting to know C#
and still writing Python code in that language, I did that.

The bottom line is that if you understand the strengths, weaknesses, and
idioms of the language you are working with right now, almost every high-level
language in common use today is sufficient for massive-scale deployments for
the most common types of web apps. Heavy computing or scientific purposes
obviously excepted. But most web apps that scale to hundreds of millions of
users are basically "window-on-data" type applications.

I can't really think of a case where some other language besides Python would
be noticeably cheaper hardware-wise.

Maybe you have to know your entire stack a bit better if you want scalable
Python apps, maybe you have to do a little more Jiggery-Pokery with your Linux
servers, but if you are serving at massive scale, you are going to have to go
there anyway, especially when you start dealing with storage. That's part of
the game.

~~~
nawitus
> Run one instance of your app per core you have available and use IPTables to
> round robin (or whatever. you can get fancier if you feel like it) to each
> app instance.

But if you're using Flask and you have 4 cores with 4 instances, and you're
making 4 database requests at the same time you're whole application is
suddenly locked. And it's not uncommon for a single view to make up to 4
separate database requests. Most modern web applications are I/O bound,
therefore a single Node.js process would have better performance here.

~~~
dorfsmay
Wait, in PROD, you don't use Python as the server, you stick uWSGI in front of
python/flask, that will deal with the network I/O limitation.

~~~
nawitus
How does uWSGI help here? The OP recommended running 4 instances of
Flask/Python, and with uWSGI you still have 4 instances. It doesn't help with
I/O.

~~~
dorfsmay
Because with uWSGI you can mix a number of threads and processes (recommended
because more processes than cores wastes time with context switches, and a low
number of threads per process is a waste of cycle. uWSGi is an event loop (not
unlike node) which makes dispatching requests to threads and processes very
easy.

------
DCPOS_Anthony
Great documentation set-out.

