What is the point of uWSGI?
Solution 1:
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.
Solution 2:
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.
Solution 3:
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
Solution 4:
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