
How I Structure My Flask Applications - llambda
http://mattupstate.com/python/2013/06/26/how-i-structure-my-flask-applications.html
======
mattdeboard
A couple other things I'd add to this good article:

\- I took a couple of good things from Django's manage.py by using Flask-
Script. It looks like [1]

\- I'm not sure if there's a better way of doing this, but I really want to be
able to swap out configurations based on which environment I'm using. I think
I've forced some Django structure onto Flask, but that said, I dynamically
load in a `settings` object and use that to configure my `app` object. I use
something like [2]. Just looking over it again I think I have some extraneous
code in there but I'm tired. It works pretty well, so far.

\- Flask-SQLAlchemy has some good stuff too but I'm not entirely sold on using
it. I'm using it on one project, but not the other. I don't miss it when I
don't have it.

1\.
[https://gist.github.com/mattdeboard/5872584](https://gist.github.com/mattdeboard/5872584)

2\.
[https://gist.github.com/mattdeboard/3cbe5395052128e60328](https://gist.github.com/mattdeboard/3cbe5395052128e60328)

~~~
mattupstate
Good call on the Flask-Script mention. I will add a note about that.

As far as configuration based on environment goes, I really dislike
environment based configuration in my project repository. So I use Flask's
instance folder functionality:

[http://flask.pocoo.org/docs/config/#instance-
folders](http://flask.pocoo.org/docs/config/#instance-folders)

This file can be used to configure the app based on its environment wether it
be local development or my production environment. The shared factory method
attempts to load this file and fails silently if it does not exist.

Regarding your SQLAlchemy comment, well...thats just not really something to
add to the article now, is it? ;)

~~~
mattdeboard
Yeah but how would this solve having identical app installations in dev, prod
and staging?

~~~
mattupstate
The settings.cfg file that I place in the instance folder is generally placed
on the server during deployment. Any values in this file will override
defaults. I generally do this with Chef or Fabric. Perhaps that answers your
question

------
mattupstate
Thanks for the mention! If anyone has further questions I'd be happy to answer
them here, or in the comments of the article itself.

~~~
aidos
Enjoyed reading through the approach you take and I'll spend some time reading
through the code tomorrow to see how it all fits together. It's surprisingly
infrequent that an article pops up describing the thought process behind using
a specific structure for your code - thanks for taking the time to write it
up.

One thing I've done differently on my last couple of projects is to put the
core parts of the app into their own packages at the top level and to make a
'web' package that just contains the web interface and the config. That way I
make sure that the core application code isn't bound to the web framework at
all. Then within my web blueprints they import the bits of the core library
they need to do their work. I can then use the main bit of the library myself
without having anything to do with the flask app.

The web app itself is responsible for creating a db connection and then
injecting that into the core when needed. I've made a simple gateway class
that wraps the db connection and deals with persistence.

The data layer is the bit I'm least happy with. Mostly that's because I went
with a nosql solution for the db which ultimately has made the data model more
complex than it needs to be. Tomorrow I'm going to experiment with switching
to SQLAlchemy again to see how that effects things.

Definitely not saying it's the right way to do things but it's another take on
how you can structure things and it's been working really well for me. Feels
like you're writing an application first and a website second - which changes
how you think about the code.

~~~
mattupstate
I hear you on the "core" library idea. I have strived for this separation
before with varying success. I just did not feel as if I wanted to go that far
with this article.

------
nikon
This is great. As a recently new Python and Flask user it's good to see how
things are done in a nicer way than I have hacked together!

Question: I have a web app built in flask, but I also require a worker process
in the background that is actively scraping websites and inserting/ updating
data into the DB via the ORM. How would you go about that in the cleanest way?

~~~
timmipetit
You could use Celery:
[http://www.celeryproject.org/](http://www.celeryproject.org/)

------
teilo
I like and use Flask, but as to how to structure it, I always end up mirroring
a classic Django structure: views, models, forms, utils, static, templates
etc. About the only thing missing is urls and admin.

It works, and it's easier for me to organize projects according to a common
standard.

~~~
mattupstate
Flask-Admin ([http://flask-admin.readthedocs.org](http://flask-
admin.readthedocs.org)) will cover you on the admin area to a certain degree.

------
canistr
As a newbie to web frameworks, I found Flask was much easier to deploy and I
understood what was happening compared to Django. I also found the
documentation and support better than that of Tornado and cherryPy.

------
malbs
Great article, but the best take away for me.. Alembic, awesome! I'd just
started to write something myself (poorly)

------
ninetenel
Just use django bro

~~~
llambda
> Just use django bro

I would be fascinated to read your rationale for just using Django.
Specifically I'm curious what use-cases you see as Django having an advantage
in? (Specific examples make for a much more interesting dialogue.) In relation
to this, do you think there are contrasting use-cases where Flask might excel
as a more suitable option? Personally, I do not favor Flask or Django or
<insert web application suite here> exclusively; instead I evaluate a use-case
and then determine which tool best fits my needs. However, it would be amazing
if you could somehow show that "just use django" is axiomatic to web
development in Python...

~~~
ninetenel
> I'm curious what use-cases you see as Django having an advantage in?

My primary use case involves having a webapp that actually works

~~~
coldtea
Whereas, in your vast experience, you found that Flask webapps don't work?

~~~
ninetenel
In production

~~~
coldtea
Whereas -- not where.

And I was being sarcastic.

