WSGI is a specification that describes the communication between web servers and Python web applications or frameworks. It explains how a web server communicates with python web applications/frameworks and how web applications/frameworks can be chained for processing a request. Python standard WSGI has been explained in detail with PEP 3333. Therefore, if you are willing to learn more about PEP 3333 you can have a look into the official documentation of Python which has been provided in the link below.
wsgi.py file in a Django project
How does WSGI work?
Now, let’s have a look at how WSGI work. So, to obtain a clear understanding of WSGI, let us assume a case scenario where you have a web application developed in Django or Flask application as shown in the figure
The above figure represents your Django/Flask application
.Since a web application is deployed in the web server. The figure below represents the web server that obtains requests from various users.
The web server which obtains requests from the users.
The above web server can be apache, NGINX, etc. server which is responsible for handling various static files and caching purposes. Furthermore, you can also use the server as a load balancer if you are willing to scale multiple applications.
Now a question arises — How can a web server interact with the Python application?
The figure representing problem in the interaction between Python application and a web server.
So, now a problem arises as a web server has to interact with a Python application.
Hence, a mediator is required for carrying out the interaction between the web servers and the Python application. So, the standard for carrying out communication between the web server and Python application is WSGI(Web Server Gateway Interface).
Now, web server is able to send requests or communicate with WSGI containers. Likewise, Python application provides a ‘callable’ object which contains certain functionalities that are invoked by WSGI application which are defined as per the PEP 3333 standard. Hence, there are multiple WSGI containers available such as Gunicorn, uWSGI, etc.
The figure below represents the communication that is carried out between web server, WSGI, and Python application.
Communication between user, web server, WSGI, and Python application.
There are multiple WSGI containers that are available today. Hence, a WSGI container is required to be installed in the project so that a web server can communicate to a WSGI container which further communicates to the Python application and provides the response back accordingly. Finally, when the web server obtains the response, it is sent back to the web browser/users.
Why use the WSGI rather than directly pointing the web server to the Django or Flask application?
If you directly point your web server to your application, it reduces the flexibility of your application. Since your web server now directly points to your web application, you are unable to swap out web stack components. Now, let’s have a look at an example to make you clear about the applicability of WSGI. For instance, today you have decided to deploy your application using Gunicorn but after some years you decide to switch from Gunicorn to mod_wsgi. Now, in this case, you can easily switch to mod_wsgi without making any changes in the application or framework that implements WSGI. Hence, WSGI provides flexibility to your application.
Another reason for using WSGI is due to its scalability. Once your application is live, up and running there can be thousands of requests in your application. Hence, WSGI is capable of serving thousands of requests at a time. As we know, the WSGI server is responsible for handling the requests from the web server and takes decision for carrying out the communication of those requests to an application framework’s process. Here, we can divide the responsibilities among the servers for scaling web traffic.
Implementation of WSGI server
There are various servers that support WSGI. If you are willing to have a look at all the servers that support WSGI, you can visit the link provided below. In this blog, I am going to provide an overview of some of the WSGI servers which are mostly used for the deployment of Flask/Django applications.
Gunicorn (Green Unicorn)
Gunicorn is a pre-fork worker model based server which is compatible with various web frameworks. Additionally, it is simple to implement. Gunicorn
Note: You can have a look at the official documentation of Gunicorn from the link provided below.
uWSGI
uWSGI is well known for being a highly-performant WSGI server implementation. uWSGI can be used for the development and deployment of Python application. In uWSGI, application servers, proxies, process managers, and monitors are all implemented through a common API and a common configuration style which makes UWSGI a developer-friendly WSGI server.
Note: You can have a look at the official documentation of uWSGI from the link provided below.
mod_wsgi
mod_wsgi is a python package that provides an Apache module which implements a WSGI compliant interface for hosting Python-based web applications on top of the Apache web server.
Note: You can have a look at the official documentation of mod_wsgi from the link provided below.
CherryPy
CherryPy is a python web framework that allows developers to develop web applications in the same way by which they develop other object-oriented Python programs. CherryPy is considered to be a reliant object-oriented HTTP framework that can efficiently run on multiple HTTP servers at once.
Note: You can have a look at the official documentation of CherryPy from the link provided below.
When should you dive deeper into WSGI?
As per my point of view, you can dive deeper into WSGI when you have to develop a new Web app framework. Hence, until and unless you are not into developing a new web application framework you can only be familiar with the purpose and applicability of WSGI. Today, web application frameworks support WSGI due to which you need not worry about the configuration and deployment of your application.
Source: Medium
The Tech Platform
Comments