Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion feeds/all.atom.xml
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"><title>Matt Makai</title><link href="http://www.fullstackpython.com/" rel="alternate"></link><link href="http://www.fullstackpython.com/feeds/all.atom.xml" rel="self"></link><id>http://www.fullstackpython.com/</id><updated>2014-02-16T09:22:08Z</updated></feed>
<feed xmlns="http://www.w3.org/2005/Atom"><title>Matt Makai</title><link href="http://www.fullstackpython.com/" rel="alternate"></link><link href="http://www.fullstackpython.com/feeds/all.atom.xml" rel="self"></link><id>http://www.fullstackpython.com/</id><updated>2014-02-16T16:47:16Z</updated></feed>
77 changes: 55 additions & 22 deletions source/content/pages/wsgi-servers.rst
Original file line number Diff line number Diff line change
Expand Up @@ -6,11 +6,11 @@ WSGI Servers
:slug: wsgi-servers
:sort-order: 07

A `Web Server Gateway Interface <http://wsgi.readthedocs.org/en/latest/>`_
(WSGI) server implements the web server side of the WSGI interface for
running Python web applications. The WSGI standard v1.0 is specified in
`PEP 0333 <http://www.python.org/dev/peps/pep-0333/>`_. As of September 2010,
WSGI v1.0 is superseded by
A `Web Server Gateway Interface <http://wsgi.readthedocs.org/en/latest/>`_
(WSGI) server implements the web server side of the WSGI interface for
running Python web applications. The WSGI standard v1.0 is specified in
`PEP 0333 <http://www.python.org/dev/peps/pep-0333/>`_. As of September 2010,
WSGI v1.0 is superseded by
`PEP 3333 <http://www.python.org/dev/peps/pep-3333/>`_, which defines the
v1.0.1 WSGI standard.

Expand All @@ -21,10 +21,10 @@ v1.0.1 WSGI standard.
:class: technical-diagram

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
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::

Expand All @@ -39,7 +39,7 @@ server running on port 8000::

# nginx should serve up static files and never send to the WSGI server
location /static {
autoindex on;
autoindex on;
alias /srv/www/assets;
}

Expand All @@ -66,33 +66,66 @@ a web developer you won't need to know much more than

* what WSGI stands for (Web Server Gateway Inteface)

* that a WSGI container is a separate running process that runs on a
* that a WSGI container is a separate running process that runs on a
different port than your web server

* 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)
runs your web application, then pass the response (in the form of HTML)
back to the requester

If you're using a standard web framework such as Django, Flask, or
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.
how they implement the WSGI standard.

However, knowing the WSGI standard and how these frameworks and containers
implement WSGI should be on your learning checklist though as you become
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.

Why WSGI?
---------

Understanding the purpose of WSGI, and WSGI servers, is just as important as
understanding their implementation. Why not just point a web server directly at
your application?
There are a couple of reasons:

* **WSGI gives you flexibility.** Because the WSGI standard has been adopted
by all Python application frameworks and many web servers, it is trivial for
an application developer to swap out components of their stack for others.
Switching web servers, WSGI servers and even frameworks becomes easy, because
the configuration pattern is the same regardless of whether you are using
NGINX, Gunicorn and Django or Apache, mod_wsgi and Flask. From `PEP 3333 <http://www.python.org/dev/peps/pep-3333/>`_:

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.

* **WSGI servers promote scaling.** If you want to serve thousands of requests
for dynamic content at once, relying on your application framework to smoothly
handle the traffic is a bad idea. Most app frameworks don't focus on serving
lots of concurrent requests gracefully. Rather, that job is left up to the WSGI
server. It will handle processing requests from the web server and deciding
how to communicate them to your application framework's process.

TODO: go into more detail about this

WSGI servers are designed with scaling in mind, and therefore their infrastructure
is better suited to handling high traffic volume than directly exposing your
application to the web.


WSGI Resources
--------------
`PEP 0333 WSGI v1.0 <http://www.python.org/dev/peps/pep-0333/>`_
`PEP 0333 WSGI v1.0 <http://www.python.org/dev/peps/pep-0333/>`_
and
`PEP 3333 WSGI v1.0.1 <http://www.python.org/dev/peps/pep-3333/>`_
`PEP 3333 WSGI v1.0.1 <http://www.python.org/dev/peps/pep-3333/>`_
specifications.

`Green Unicorn <http://gunicorn.org/>`_,
`Green Unicorn <http://gunicorn.org/>`_,
`mod_wsgi <http://code.google.com/p/modwsgi/>`_,
`uWSGI <https://github.com/unbit/uwsgi-docs>`_, and
`gevent <http://www.gevent.org/>`_ are common WSGI server implementations.
Expand All @@ -103,7 +136,7 @@ contains a simple example of how a WSGI-compatible application works.
`Complete single server Django stack tutorial <http://www.apreche.net/complete-single-server-django-stack-tutorial/>`_ is thorough and informative for
non-paas hosting choices.

This detailed post entitled
`The Beautiful Simplicity of an nginx and uWSGI Deployments <http://bartek.im/blog/2012/07/08/simplicity-nginx-uwsgi-deployment.html>`_
is great reading for understanding Nginx and uWSGI configurations.
This detailed post entitled
`The Beautiful Simplicity of an nginx and uWSGI Deployments <http://bartek.im/blog/2012/07/08/simplicity-nginx-uwsgi-deployment.html>`_
is great reading for understanding Nginx and uWSGI configurations.

33 changes: 33 additions & 0 deletions wsgi-servers.html
Original file line number Diff line number Diff line change
Expand Up @@ -142,6 +142,39 @@ <h1>WSGI Servers</h1>
<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="why-wsgi">
<h2>Why WSGI?</h2>
<p>Understanding the purpose of WSGI, and WSGI servers, is just as important as
understanding their implementation. Why not just point a web server directly at
your application?
There are a couple of reasons:</p>
<ul>
<li><p class="first"><strong>WSGI gives you flexibility.</strong> Because the WSGI standard has been adopted
by all Python application frameworks and many web servers, it is trivial for
an application developer to swap out components of their stack for others.
Switching web servers, WSGI servers and even frameworks becomes easy, because
the configuration pattern is the same regardless of whether you are using
NGINX, Gunicorn and Django or Apache, mod_wsgi and Flask. 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> If you want to serve thousands of requests
for dynamic content at once, relying on your application framework to smoothly
handle the traffic is a bad idea. Most app frameworks don't focus on serving
lots of concurrent requests gracefully. Rather, that job is left up to the WSGI
server. It will handle processing requests from the web server and deciding
how to communicate them to your application framework's process.</p>
<p>TODO: go into more detail about this</p>
<p>WSGI servers are designed with scaling in mind, and therefore their infrastructure
is better suited to handling high traffic volume than directly exposing your
application to the web.</p>
</li>
</ul>
</div>
<div class="section" id="wsgi-resources">
<h2>WSGI Resources</h2>
<p><a class="reference external" href="http://www.python.org/dev/peps/pep-0333/">PEP 0333 WSGI v1.0</a>
Expand Down