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?

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

Solution 5

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.

View more solutions

Comments

[d512]

There are three things here: nginx, uwsgi, and flask. How does it all fit together in context of the WSGI spec? Is nginx the server and uwsgi is the app or is uwsgi the server and flask is the app?

[Rafiqul Hasan]

uWSGI is the server and flask is app.

[d512]

Well, if you don't mind, check out my answer to my own question and see what you think.

[jdogg]

Why doesn't a web server understand Python apps? It can understand PHP, why not Python or other languages?

[Sergey Panfilov]

It is possible to run Flask applications with Werkzeug as an HTTP server, but it is not production ready setup. uWSGI solves multiple problems: * HTTP parsing (faster in C) and interfacing with WSGI app * launches app in multiple processes/threads for better concurrency * acts as a supervisor of WSGI apps

[TomSawyer]

@SergeyPanfilov the trouble is we don't know how uwsgi dealing with flask, each process / threads created one instance of flask app? i've seen some implementation for background task in flask like Flask-Executor and it have to bind inside an request. Can't be place outside of context.

[overexchange]

Read the answer from Hasan.. it is close to correct answer..... http servers are mostly written in C and they cannot forward the http requests to python backends....your answer just talks about the mechanics

[Dondi Michael Stroma]

jdogg Web servers don't natively understand PHP apps either, they're either using CGI (an outdated and slow interface), FastCGI (which could be seen as a "competitor" to uwsgi), or it is Apache with mod_php. Yes, Apache has a mod_python too...and modules for other languages, but having your webserver also be your application server at the same time is also an outdated idea for reasons of performance, configuration, memory usage, and security. No reason a 100MB Apache instance needs to serve your favicon.ico file.