Is manage.py the right way to organize / write Flask apps?
Let me start by saying that I feel very stupid asking this question because I cannot find a thread / article I read a while ago explaining the reasons for not using manage.py.
I recently launched a web application and I was really struggling with converting from format manage.py runserver
to gunicorn app:app
. Did I do something wrong? If it was a breeze, and is this how it is done?
I think what I'm really asking is: Regarding manage.py runserver
etc, what's the way to write an application and then configure it for deployment using, say, gunicorn?
If anyone is confusing my question, ask me because I will really like the answer to this question as I am planning to create another app in the near future. Thanks in advance!
source to share
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 functionality for Flask.
The simplest "control" script simply imports an application instance (or creates one from a factory) and runs it or runs another command in 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 eventually it ends up. It should be obvious by now that it gunicorn my_app:app
does the same. Instead of running the dev server, gunicorn is a production application server using the same application instance that the dev server will use.
source to share
This answer applies to both Django and Flask (and all other Python wsgi frameworks, AFAIK):
Apps like Flask and Django have a lightweight built-in server to help you develop. These are fully functional HTTP servers that could theoretically be used in production. But you shouldn't .
The reason you shouldn't be because these servers are generally very simple, single threaded, and very uncomplicated. This is good from a developmental point of view because you don't have to worry about setting this, this, and the other. Plus, they can do nifty things like restarting the app for you when you make changes.
But they only expect one user to touch the page at a time. You, the developer.
This is not what you want in production.
In production, you need a web server capable of handling thousands of requests per second, either through streams (but possibly not ) or a reactor. You do not want your web server to stop responding to other requests when you are processing a long request or file upload. This is where servers like Gunicorn or Tornado come in - they allow tons of connections to be made at the same time and they can handle communication between your Django / Flask / Bottle / CherryPy / etc. applications and the Internet in general. This is a good thing.
The process doesn't have to be complicated to communicate with the built-in wsgi server, machine gun / tornado, or anything else that can run a wsgi application. That is the whole point of the wsgi layer.
If there is a problem with the conversion, either you have problems with your understanding, or your application is misconfigured. Both of these issues are issues that the SO community can help, and there are probably several issues that address most of the more common scenarios already.
source to share