You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
<meta name="description" content="Full Stack Python shows how an entire Python web application is built and deployed. Each section of the guide explains a different key concept, from the server through the Python WSGI web framework to the front end JavaScript.">
<p>A <a class="reference external" href="http://wsgi.readthedocs.org/en/latest/">Web Server Gateway Interface</a>
(WSGI) server implements the web server side of the WSGI interface for
running Python web applications. The WSGI standard v1.0 is specified in
<a class="reference external" href="http://www.python.org/dev/peps/pep-0333/">PEP 0333</a>. As of September 2010,
WSGI v1.0 is superseded by
<a class="reference external" href="http://www.python.org/dev/peps/pep-3333/">PEP 3333</a>, which defines the
v1.0.1 WSGI standard.</p>
<img alt="WSGI Server <-> Web server <-> Browser" class="technical-diagram" src="theme/img/web-browser-server-wsgi.png" style="width: 100%;" />
<p>A web server's configuration specifies what requests should be passed to
the WSGI server to process. Once a request is processed and generated by the
WSGI server, the response is passed back through the web server and onto
the browser. For example, this Nginx web server's configuration specifics
Nginx should handle static assets (such as images, JavaScript, and CSS
files) under the /static directory and pass all other requests to the WSGI
server running on port 8000:</p>
<pre class="literal-block">
# this specifies that there is a WSGI server running on port 8000
upstream app_server_djangoapp {
server localhost:8000 fail_timeout=0;
}
# Nginx is set up to run on the standard HTTP port and listen for requests
server {
listen 80;
# nginx should serve up static files and never send to the WSGI server
location /static {
autoindex on;
alias /srv/www/assets;
}
# requests that do not fall under /static are passed on to the WSGI
# server that was specified above running on port 8000
<p>Note that the above code is a simplified version of a production-ready Nginx
configuration. For real SSL and non-SSL templates, take a look at the
<a class="reference external" href="https://github.com/makaimc/underwear/tree/master/underwear/roles/web/templates">Underwear web server templates</a> on GitHub.</p>
<p>WSGI is by design a simple standard interface for running Python code. As
a web developer you won't need to know much more than</p>
<ul class="simple">
<li>what WSGI stands for (Web Server Gateway Inteface)</li>
<li>that a WSGI container is a separate running process that runs on a
different port than your web server</li>
<li>your web server is configured to pass requests to the WSGI container which
runs your web application, then pass the response (in the form of HTML)
back to the requester</li>
</ul>
<p>If you're using a standard web framework such as Django, Flask, or
Bottle, or almost any other current Python framework, you don't need to worry
about how frameworks implement the application side of the WSGI standard.
Likewise, if you're using a standard WSGI container such as Green Unicorn,
uWSGI, mod_wsgi, or gevent, you can get them running without worrying about
how they implement the WSGI standard.</p>
<p>However, knowing the WSGI standard and how these frameworks and containers
implement WSGI should be on your learning checklist though as you become
a more experienced Python web developer.</p>
<div class="section" id="wsgi-s-purpose">
<h2>WSGI's Purpose</h2>
<p>Why use WSGI and not just point a web server directly at an application?</p>
<ul>
<li><p class="first"><strong>WSGI gives you flexibility</strong>. Application developers can swap out
web stack components for others. For example, a developer can switch from
Green Unicorn to uWSGI without modifying the application or framework
that implements WSGI.
From <a class="reference external" href="http://www.python.org/dev/peps/pep-3333/">PEP 3333</a>:</p>
<blockquote>
<p>The availability and widespread use of such an API in web servers for
Python [...] would separate choice of framework from choice of web
server, freeing users to choose a pairing that suits them, while
freeing framework and server developers to focus on their preferred
area of specialization.</p>
</blockquote>
</li>
<li><p class="first"><strong>WSGI servers promote scaling</strong>. Serving thousands of requests for dynamic
content at once is the domain of WSGI servers, not frameworks.
WSGI servers handle processing requests from the web server and deciding
how to communicate those requests to an application framework's process.
The segregation of responsibilities is important for efficiently scaling
<a class="reference external" href="https://github.com/unbit/uwsgi-docs">uWSGI</a>, and
<a class="reference external" href="http://www.gevent.org/">gevent</a> are common WSGI server implementations.</p>
<p>This <a class="reference external" href="http://agiliq.com/blog/2013/07/basics-wsgi/">Basics of WSGI</a> post
contains a simple example of how a WSGI-compatible application works.</p>
<p><a class="reference external" href="http://www.apreche.net/complete-single-server-django-stack-tutorial/">Complete single server Django stack tutorial</a> is thorough and informative for
non-paas hosting choices.</p>
<p>This detailed post entitled
<a class="reference external" href="http://bartek.im/blog/2012/07/08/simplicity-nginx-uwsgi-deployment.html">The Beautiful Simplicity of an nginx and uWSGI Deployments</a>
is great reading for understanding Nginx and uWSGI configurations.</p>