Is manage.py the proper way to organize/write Flask apps?

Question

Let me start off by saying I feel very silly asking this question, because I cannot find the thread/article that I read some time ago providing the reasons to not use manage.py.

I recently launched a web app and I really struggled with converting from manage.py runserver to gunicorn app:app format. Did i do something wrong? Should it have been a breeze and is this the way it is done?

I guess what i'm really asking is: Regarding manage.py runserver etc., what is the proper way to write an app and then set it up to deploy using, lets say, gunicorn?

If anyone is confused by my question, please ask me, because I really would love an answer to this as I am planning on building another app in the near future. Thanks in advance!

Answer 1

manage.py is a common concept in web frameworks. It is used to run commands and start the development server. The Flask-Script extension provides this function for Flask.

The simplest "management" script simply imports the app instance (or creates one from a factory and runs it, or runs another command inside the application context.

from my_app import app
app.run()
# or for custom commands
with app.app_context():
    do_command()

Flask-Script does more, but it comes down to that in the end. Now it should be obvious that gunicorn my_app:app is doing the same thing. Rather than run the dev server, gunicorn is a production application server, using the same app instance that the dev server would use.

Answer 2

This answer applies to both Django and Flask (and all other Python wsgi frameworks, AFAIK):

Applications like Flask and Django come with a lightweight webserver builtin that will help you out when you're developing. They're fully functional HTTP servers, that in theory you could use in production. But you shouldn't.

The reason you shouldn't is that these servers tend to be very basic, single-threaded, and very uncomplicated. This is a good thing from the perspective of development, because you don't have to worry about installing this, that, and the other. Plus they might do nifty things like reload your application for you when you make a change.

But they only expect one user to be touching the page at a time. You, the developer.

This is not what you want in production.

In production you want a web server that is capable of handling thousands of requests per second, either via threading (but probably not) or the reactor pattern. You don't want your web server to stop responding to other requests when you handle a long-running query or file upload. This is where servers like Gunicorn or Tornado come in - they allow a ton of connections to happen at once, and they're able to handle communication between your Django/Flask/Bottle/CherryPy/etc. application and the Internet at large. That's a good thing.

The process should not be a complicated one to swap from the built-in wsgi server and gunicorn/tornado or anything else that can run a wsgi application. That's the whole point of the wsgi layer.

If there is some problem converting either you have some problems with your understanding, or your application is misconfigured. Both of those are problems that the SO community can help, and there are probably a few questions that already address most of the more common scenarios.