Skip to content

Commit d7bbe8d

Browse files
committed
Added a 'Why WSGI?' section to the WSGI server page. WIP.
1 parent b3ef414 commit d7bbe8d

File tree

3 files changed

+89
-23
lines changed

3 files changed

+89
-23
lines changed

feeds/all.atom.xml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,2 +1,2 @@
11
<?xml version="1.0" encoding="utf-8"?>
2-
<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>
2+
<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>

source/content/pages/wsgi-servers.rst

Lines changed: 55 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -6,11 +6,11 @@ WSGI Servers
66
:slug: wsgi-servers
77
:sort-order: 07
88

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

@@ -21,10 +21,10 @@ v1.0.1 WSGI standard.
2121
:class: technical-diagram
2222

2323
A web server's configuration specifies what requests should be passed to
24-
the WSGI server to process. Once a request is processed and generated by the
25-
WSGI server, the response is passed back through the web server and onto
26-
the browser. For example, this Nginx web server's configuration specifics
27-
Nginx should handle static assets (such as images, JavaScript, and CSS
24+
the WSGI server to process. Once a request is processed and generated by the
25+
WSGI server, the response is passed back through the web server and onto
26+
the browser. For example, this Nginx web server's configuration specifics
27+
Nginx should handle static assets (such as images, JavaScript, and CSS
2828
files) under the /static directory and pass all other requests to the WSGI
2929
server running on port 8000::
3030

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

4040
# nginx should serve up static files and never send to the WSGI server
4141
location /static {
42-
autoindex on;
42+
autoindex on;
4343
alias /srv/www/assets;
4444
}
4545

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

6767
* what WSGI stands for (Web Server Gateway Inteface)
6868

69-
* that a WSGI container is a separate running process that runs on a
69+
* that a WSGI container is a separate running process that runs on a
7070
different port than your web server
7171

7272
* your web server is configured to pass requests to the WSGI container which
73-
runs your web application, then pass the response (in the form of HTML)
73+
runs your web application, then pass the response (in the form of HTML)
7474
back to the requester
7575

76-
If you're using a standard web framework such as Django, Flask, or
76+
If you're using a standard web framework such as Django, Flask, or
7777
Bottle, or almost any other current Python framework, you don't need to worry
7878
about how frameworks implement the application side of the WSGI standard.
7979
Likewise, if you're using a standard WSGI container such as Green Unicorn,
8080
uWSGI, mod_wsgi, or gevent, you can get them running without worrying about
81-
how they implement the WSGI standard.
81+
how they implement the WSGI standard.
8282

83-
However, knowing the WSGI standard and how these frameworks and containers
84-
implement WSGI should be on your learning checklist though as you become
83+
However, knowing the WSGI standard and how these frameworks and containers
84+
implement WSGI should be on your learning checklist though as you become
8585
a more experienced Python web developer.
8686

87+
Why WSGI?
88+
---------
89+
90+
Understanding the purpose of WSGI, and WSGI servers, is just as important as
91+
understanding their implementation. Why not just point a web server directly at
92+
your application?
93+
There are a couple of reasons:
94+
95+
* **WSGI gives you flexibility.** Because the WSGI standard has been adopted
96+
by all Python application frameworks and many web servers, it is trivial for
97+
an application developer to swap out components of their stack for others.
98+
Switching web servers, WSGI servers and even frameworks becomes easy, because
99+
the configuration pattern is the same regardless of whether you are using
100+
NGINX, Gunicorn and Django or Apache, mod_wsgi and Flask. From `PEP 3333 <http://www.python.org/dev/peps/pep-3333/>`_:
101+
102+
The availability and widespread use of such an API in web servers for Python
103+
[...] would separate choice of framework from choice of web server, freeing
104+
users to choose a pairing that suits them, while freeing framework and
105+
server developers to focus on their preferred area of specialization.
106+
107+
* **WSGI servers promote scaling.** If you want to serve thousands of requests
108+
for dynamic content at once, relying on your application framework to smoothly
109+
handle the traffic is a bad idea. Most app frameworks don't focus on serving
110+
lots of concurrent requests gracefully. Rather, that job is left up to the WSGI
111+
server. It will handle processing requests from the web server and deciding
112+
how to communicate them to your application framework's process.
113+
114+
TODO: go into more detail about this
115+
116+
WSGI servers are designed with scaling in mind, and therefore their infrastructure
117+
is better suited to handling high traffic volume than directly exposing your
118+
application to the web.
119+
87120

88121
WSGI Resources
89122
--------------
90-
`PEP 0333 WSGI v1.0 <http://www.python.org/dev/peps/pep-0333/>`_
123+
`PEP 0333 WSGI v1.0 <http://www.python.org/dev/peps/pep-0333/>`_
91124
and
92-
`PEP 3333 WSGI v1.0.1 <http://www.python.org/dev/peps/pep-3333/>`_
125+
`PEP 3333 WSGI v1.0.1 <http://www.python.org/dev/peps/pep-3333/>`_
93126
specifications.
94127

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

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

wsgi-servers.html

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -142,6 +142,39 @@ <h1>WSGI Servers</h1>
142142
<p>However, knowing the WSGI standard and how these frameworks and containers
143143
implement WSGI should be on your learning checklist though as you become
144144
a more experienced Python web developer.</p>
145+
<div class="section" id="why-wsgi">
146+
<h2>Why WSGI?</h2>
147+
<p>Understanding the purpose of WSGI, and WSGI servers, is just as important as
148+
understanding their implementation. Why not just point a web server directly at
149+
your application?
150+
There are a couple of reasons:</p>
151+
<ul>
152+
<li><p class="first"><strong>WSGI gives you flexibility.</strong> Because the WSGI standard has been adopted
153+
by all Python application frameworks and many web servers, it is trivial for
154+
an application developer to swap out components of their stack for others.
155+
Switching web servers, WSGI servers and even frameworks becomes easy, because
156+
the configuration pattern is the same regardless of whether you are using
157+
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>
158+
<blockquote>
159+
<p>The availability and widespread use of such an API in web servers for Python
160+
[...] would separate choice of framework from choice of web server, freeing
161+
users to choose a pairing that suits them, while freeing framework and
162+
server developers to focus on their preferred area of specialization.</p>
163+
</blockquote>
164+
</li>
165+
<li><p class="first"><strong>WSGI servers promote scaling.</strong> If you want to serve thousands of requests
166+
for dynamic content at once, relying on your application framework to smoothly
167+
handle the traffic is a bad idea. Most app frameworks don't focus on serving
168+
lots of concurrent requests gracefully. Rather, that job is left up to the WSGI
169+
server. It will handle processing requests from the web server and deciding
170+
how to communicate them to your application framework's process.</p>
171+
<p>TODO: go into more detail about this</p>
172+
<p>WSGI servers are designed with scaling in mind, and therefore their infrastructure
173+
is better suited to handling high traffic volume than directly exposing your
174+
application to the web.</p>
175+
</li>
176+
</ul>
177+
</div>
145178
<div class="section" id="wsgi-resources">
146179
<h2>WSGI Resources</h2>
147180
<p><a class="reference external" href="http://www.python.org/dev/peps/pep-0333/">PEP 0333 WSGI v1.0</a>

0 commit comments

Comments
 (0)