Skip to content

Commit 21dd6c0

Browse files
mattmakaimattmakai
committed
polishing WSGI section
1 parent ba9381e commit 21dd6c0

File tree

5 files changed

+47
-61
lines changed

5 files changed

+47
-61
lines changed

‎change-log.html‎

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -83,7 +83,8 @@ <h2>2014</h2>
8383
Merged several pull requests (see closed
8484
<a class="reference external" href="https://github.com/makaimc/fullstackpython.github.com/pulls">GitHub repo pull requests</a>). New resources for platform-as-a-service section. Adding new
8585
sections specified by the community as missing. Reorganized ordering of
86-
content. Broke out subsections for Django and Flask.</p>
86+
content. Broke out subsections for Django and Flask. Added signficant
87+
content to the WSGI section.</p>
8788
<p>Jan: Adding configuration management, application dependencies, and source
8889
control sections. Also updating about section. Updated design to be fully
8990
responsive.</p>

‎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-16T16:47:16Z</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-17T08:25:09Z</updated></feed>

‎source/content/pages/change-log.rst‎

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,8 @@ Added task queues section due to reader feedback. Rewrote intro section.
1414
Merged several pull requests (see closed
1515
`GitHub repo pull requests <https://github.com/makaimc/fullstackpython.github.com/pulls>`_). New resources for platform-as-a-service section. Adding new
1616
sections specified by the community as missing. Reorganized ordering of
17-
content. Broke out subsections for Django and Flask.
17+
content. Broke out subsections for Django and Flask. Added signficant
18+
content to the WSGI section.
1819

1920
Jan: Adding configuration management, application dependencies, and source
2021
control sections. Also updating about section. Updated design to be fully

‎source/content/pages/wsgi-servers.rst‎

Lines changed: 23 additions & 32 deletions
Original file line numberDiff line numberDiff line change
@@ -84,38 +84,29 @@ However, knowing the WSGI standard and how these frameworks and containers
8484
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.
87+
88+
WSGI's Purpose
89+
--------------
90+
Why use WSGI and not just point a web server directly at an application?
91+
92+
* **WSGI gives you flexibility**. Application developers can swap out
93+
web stack components for others. For example, a developer can switch from
94+
Green Unicorn to uWSGI without modifying the application or framework
95+
that implements WSGI.
96+
From `PEP 3333 <http://www.python.org/dev/peps/pep-3333/>`_:
97+
98+
The availability and widespread use of such an API in web servers for
99+
Python [...] would separate choice of framework from choice of web
100+
server, freeing users to choose a pairing that suits them, while
101+
freeing framework and server developers to focus on their preferred
102+
area of specialization.
103+
104+
* **WSGI servers promote scaling**. Serving thousands of requests for dynamic
105+
content at once is the domain of WSGI servers, not frameworks.
106+
WSGI servers handle processing requests from the web server and deciding
107+
how to communicate those requests to an application framework's process.
108+
The segregation of responsibilities is important for efficiently scaling
109+
web traffic.
119110

120111

121112
WSGI Resources

‎wsgi-servers.html‎

Lines changed: 19 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -142,36 +142,29 @@ <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>
145+
<div class="section" id="wsgi-s-purpose">
146+
<h2>WSGI's Purpose</h2>
147+
<p>Why use WSGI and not just point a web server directly at an application?</p>
151148
<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>
149+
<li><p class="first"><strong>WSGI gives you flexibility</strong>. Application developers can swap out
150+
web stack components for others. For example, a developer can switch from
151+
Green Unicorn to uWSGI without modifying the application or framework
152+
that implements WSGI.
153+
From <a class="reference external" href="http://www.python.org/dev/peps/pep-3333/">PEP 3333</a>:</p>
158154
<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>
155+
<p>The availability and widespread use of such an API in web servers for
156+
Python [...] would separate choice of framework from choice of web
157+
server, freeing users to choose a pairing that suits them, while
158+
freeing framework and server developers to focus on their preferred
159+
area of specialization.</p>
163160
</blockquote>
164161
</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>
162+
<li><p class="first"><strong>WSGI servers promote scaling</strong>. Serving thousands of requests for dynamic
163+
content at once is the domain of WSGI servers, not frameworks.
164+
WSGI servers handle processing requests from the web server and deciding
165+
how to communicate those requests to an application framework's process.
166+
The segregation of responsibilities is important for efficiently scaling
167+
web traffic.</p>
175168
</li>
176169
</ul>
177170
</div>

0 commit comments

Comments
 (0)