What is the point of uWSGI?
Question:
I’m looking at the WSGI specification and I’m trying to figure out how servers like uWSGI fit into the picture. I understand the point of the WSGI spec is to separate web servers like nginx from web applications like something you’d write using Flask. What I don’t understand is what uWSGI is for. Why can’t nginx directly call my Flask application? Can’t flask speak WSGI directly to it? Why does uWSGI need to get in between them?
There are two sides in the WSGI spec: the server and the web app. Which side is uWSGI on?
Answers:
A traditional web server does not understand or have any way to run Python applications. That’s why WSGI server come in. On the other hand Nginx supports reverse proxy to handle requests and pass back responses for Python WSGI servers.
This link might help you: https://www.fullstackpython.com/wsgi-servers.html
Okay, I think I get this now.
Why can’t nginx directly call my Flask application?
Because nginx doesn’t support the WSGI spec. Technically nginx could implement the WSGI spec if they wanted, they just haven’t.
That being the case, we need a web server that does implement the spec, which is what the uWSGI server is for.
Note that uWSGI is a full fledged http server that can and does work well on its own. I’ve used it in this capacity several times and it works great. If you need super high throughput for static content, then you have the option of sticking nginx in front of your uWSGI server. When you do, they will communicate over a low level protocol known as uwsgi.
“What the what?! Another thing called uwsgi?!” you ask. Yeah, it’s confusing. When you reference uWSGI you are talking about an http server. When you talk about uwsgi (all lowercase) you are talking about a binary protocol that the uWSGI server uses to talk to other servers like nginx. They picked a bad name on this one.
For anyone who is interested, I wrote a blog article about it with more specifics, a bit of history, and some examples.
NGINX in this case only works as a reverse proxy and render static files not the dynamic files, it receives the requests and proxies them to the application server, that would be UWSGI.
The UWSGI server is responsible for loading your Flask application using the WSGI interface. You can actually make UWSGI listen directly to requests from the internet and remove NGINX if you like, although it’s mostly used behind a reverse proxy.
From the docs:
uWSGI supports several methods of integrating with web servers. It is also capable of serving HTTP requests by itself.
WSGI is just an interface specification, in simple terms, it tells you what methods should be implemented for passing requests and responses between the server and the application. When using frameworks such as Flask or Django, this is handled by the framework itself.
In other words, WSGI is basically a contract between python applications (Flask, Django, etc) and web servers (UWSGI, Gunicorn, etc). The benefit is that you can change web servers with little effort because you know they comply with the WSGI specification, which is actually one of the goals, as stated in PEP-333.
Python currently boasts a wide variety of web application frameworks, such as Zope, Quixote, Webware, SkunkWeb, PSO, and Twisted Web — to name just a few 1. This wide variety of choices can be a problem for new Python users, because generally speaking, their choice of web framework will limit their choice of usable web servers, and vice versa.
In simple terms, just think of an analogy where you are running a CGI or PHP application with Nginx web server. You will use the respective handlers like php-fpm to run these files since the webserver, in its native form doesn’t render these formats.
There is an important aspect which we are missing . Flask and Django are web frameworks and we build web applications out of them . uWSGI or Gunicorn process the framework files . Consider it as a software application sitting in between the Django app and Nginx . uWSGI and Nginx communicate using WSGI but there is no communication interface between Django and uWSGI . Check out this video https://www.youtube.com/watch?v=WqrCnVAkLIo
I’m looking at the WSGI specification and I’m trying to figure out how servers like uWSGI fit into the picture. I understand the point of the WSGI spec is to separate web servers like nginx from web applications like something you’d write using Flask. What I don’t understand is what uWSGI is for. Why can’t nginx directly call my Flask application? Can’t flask speak WSGI directly to it? Why does uWSGI need to get in between them?
There are two sides in the WSGI spec: the server and the web app. Which side is uWSGI on?
A traditional web server does not understand or have any way to run Python applications. That’s why WSGI server come in. On the other hand Nginx supports reverse proxy to handle requests and pass back responses for Python WSGI servers.
This link might help you: https://www.fullstackpython.com/wsgi-servers.html
Okay, I think I get this now.
Why can’t nginx directly call my Flask application?
Because nginx doesn’t support the WSGI spec. Technically nginx could implement the WSGI spec if they wanted, they just haven’t.
That being the case, we need a web server that does implement the spec, which is what the uWSGI server is for.
Note that uWSGI is a full fledged http server that can and does work well on its own. I’ve used it in this capacity several times and it works great. If you need super high throughput for static content, then you have the option of sticking nginx in front of your uWSGI server. When you do, they will communicate over a low level protocol known as uwsgi.
“What the what?! Another thing called uwsgi?!” you ask. Yeah, it’s confusing. When you reference uWSGI you are talking about an http server. When you talk about uwsgi (all lowercase) you are talking about a binary protocol that the uWSGI server uses to talk to other servers like nginx. They picked a bad name on this one.
For anyone who is interested, I wrote a blog article about it with more specifics, a bit of history, and some examples.
NGINX in this case only works as a reverse proxy and render static files not the dynamic files, it receives the requests and proxies them to the application server, that would be UWSGI.
The UWSGI server is responsible for loading your Flask application using the WSGI interface. You can actually make UWSGI listen directly to requests from the internet and remove NGINX if you like, although it’s mostly used behind a reverse proxy.
From the docs:
uWSGI supports several methods of integrating with web servers. It is also capable of serving HTTP requests by itself.
WSGI is just an interface specification, in simple terms, it tells you what methods should be implemented for passing requests and responses between the server and the application. When using frameworks such as Flask or Django, this is handled by the framework itself.
In other words, WSGI is basically a contract between python applications (Flask, Django, etc) and web servers (UWSGI, Gunicorn, etc). The benefit is that you can change web servers with little effort because you know they comply with the WSGI specification, which is actually one of the goals, as stated in PEP-333.
Python currently boasts a wide variety of web application frameworks, such as Zope, Quixote, Webware, SkunkWeb, PSO, and Twisted Web — to name just a few 1. This wide variety of choices can be a problem for new Python users, because generally speaking, their choice of web framework will limit their choice of usable web servers, and vice versa.
In simple terms, just think of an analogy where you are running a CGI or PHP application with Nginx web server. You will use the respective handlers like php-fpm to run these files since the webserver, in its native form doesn’t render these formats.
There is an important aspect which we are missing . Flask and Django are web frameworks and we build web applications out of them . uWSGI or Gunicorn process the framework files . Consider it as a software application sitting in between the Django app and Nginx . uWSGI and Nginx communicate using WSGI but there is no communication interface between Django and uWSGI . Check out this video https://www.youtube.com/watch?v=WqrCnVAkLIo