Skip to content

Commit 797c893

Browse files
mattmakaimattmakai
committed
reordering WSGI page
1 parent 5293700 commit 797c893

File tree

3 files changed

+98
-98
lines changed

3 files changed

+98
-98
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-03-15T10:28:04Z</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-03-15T10:31:10Z</updated></feed>

‎source/content/pages/07-wsgi-servers/0701-wsgi-servers.markdown‎

Lines changed: 47 additions & 47 deletions
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,53 @@ modules and containers could implement to run Python applications. WSGI is
2929
now the accepted approach for running Python web application code.
3030

3131

32-
## PEP specification
32+
## WSGI's Purpose
33+
Why use WSGI and not just point a web server directly at an application?
34+
35+
* **WSGI gives you flexibility**. Application developers can swap out
36+
web stack components for others. For example, a developer can switch from
37+
Green Unicorn to uWSGI without modifying the application or framework
38+
that implements WSGI.
39+
From [PEP 3333](http://www.python.org/dev/peps/pep-3333/):
40+
41+
The availability and widespread use of such an API in web servers for
42+
Python [...] would separate choice of framework from choice of web
43+
server, freeing users to choose a pairing that suits them, while
44+
freeing framework and server developers to focus on their preferred
45+
area of specialization.
46+
47+
* **WSGI servers promote scaling**. Serving thousands of requests for dynamic
48+
content at once is the domain of WSGI servers, not frameworks.
49+
WSGI servers handle processing requests from the web server and deciding
50+
how to communicate those requests to an application framework's process.
51+
The segregation of responsibilities is important for efficiently scaling
52+
web traffic.
53+
54+
WSGI is by design a simple standard interface for running Python code. As
55+
a web developer you won't need to know much more than
56+
57+
* what WSGI stands for (Web Server Gateway Inteface)
58+
59+
* that a WSGI container is a separate running process that runs on a
60+
different port than your web server
61+
62+
* your web server is configured to pass requests to the WSGI container which
63+
runs your web application, then pass the response (in the form of HTML)
64+
back to the requester
65+
66+
If you're using a standard web framework such as Django, Flask, or
67+
Bottle, or almost any other current Python framework, you don't need to worry
68+
about how frameworks implement the application side of the WSGI standard.
69+
Likewise, if you're using a standard WSGI container such as Green Unicorn,
70+
uWSGI, mod\_wsgi, or gevent, you can get them running without worrying about
71+
how they implement the WSGI standard.
72+
73+
However, knowing the WSGI standard and how these frameworks and containers
74+
implement WSGI should be on your learning checklist though as you become
75+
a more experienced Python web developer.
76+
77+
78+
## Official WSGI specifications
3379
The WSGI standard v1.0 is specified in
3480
[PEP 0333](http://www.python.org/dev/peps/pep-0333/). As of September 2010,
3581
WSGI v1.0 is superseded by
@@ -83,52 +129,6 @@ Note that the above code is a simplified version of a production-ready Nginx
83129
configuration. For real SSL and non-SSL templates, take a look at the
84130
[Underwear web server templates](https://github.com/makaimc/underwear/tree/master/underwear/roles/web/templates) on GitHub.
85131

86-
WSGI is by design a simple standard interface for running Python code. As
87-
a web developer you won't need to know much more than
88-
89-
* what WSGI stands for (Web Server Gateway Inteface)
90-
91-
* that a WSGI container is a separate running process that runs on a
92-
different port than your web server
93-
94-
* your web server is configured to pass requests to the WSGI container which
95-
runs your web application, then pass the response (in the form of HTML)
96-
back to the requester
97-
98-
If you're using a standard web framework such as Django, Flask, or
99-
Bottle, or almost any other current Python framework, you don't need to worry
100-
about how frameworks implement the application side of the WSGI standard.
101-
Likewise, if you're using a standard WSGI container such as Green Unicorn,
102-
uWSGI, mod\_wsgi, or gevent, you can get them running without worrying about
103-
how they implement the WSGI standard.
104-
105-
However, knowing the WSGI standard and how these frameworks and containers
106-
implement WSGI should be on your learning checklist though as you become
107-
a more experienced Python web developer.
108-
109-
110-
## WSGI's Purpose
111-
Why use WSGI and not just point a web server directly at an application?
112-
113-
* **WSGI gives you flexibility**. Application developers can swap out
114-
web stack components for others. For example, a developer can switch from
115-
Green Unicorn to uWSGI without modifying the application or framework
116-
that implements WSGI.
117-
From [PEP 3333](http://www.python.org/dev/peps/pep-3333/):
118-
119-
The availability and widespread use of such an API in web servers for
120-
Python [...] would separate choice of framework from choice of web
121-
server, freeing users to choose a pairing that suits them, while
122-
freeing framework and server developers to focus on their preferred
123-
area of specialization.
124-
125-
* **WSGI servers promote scaling**. Serving thousands of requests for dynamic
126-
content at once is the domain of WSGI servers, not frameworks.
127-
WSGI servers handle processing requests from the web server and deciding
128-
how to communicate those requests to an application framework's process.
129-
The segregation of responsibilities is important for efficiently scaling
130-
web traffic.
131-
132132

133133
## WSGI Resources
134134
* [PEP 0333 WSGI v1.0](http://www.python.org/dev/peps/pep-0333/)

‎wsgi-servers.html‎

Lines changed: 50 additions & 50 deletions
Original file line numberDiff line numberDiff line change
@@ -92,7 +92,56 @@ <h2>Why are WSGI servers necessary?</h2>
9292
<p>Therefore the Python community came up with WSGI as a standard interface that<br />
9393
modules and containers could implement to run Python applications. WSGI is
9494
now the accepted approach for running Python web application code. </p>
95-
<h2>PEP specification</h2>
95+
<h2>WSGI's Purpose</h2>
96+
<p>Why use WSGI and not just point a web server directly at an application?</p>
97+
<ul>
98+
<li>
99+
<p><strong>WSGI gives you flexibility</strong>. Application developers can swap out
100+
web stack components for others. For example, a developer can switch from
101+
Green Unicorn to uWSGI without modifying the application or framework
102+
that implements WSGI.
103+
From <a href="http://www.python.org/dev/peps/pep-3333/">PEP 3333</a>:</p>
104+
<p>The availability and widespread use of such an API in web servers for
105+
Python [...] would separate choice of framework from choice of web
106+
server, freeing users to choose a pairing that suits them, while
107+
freeing framework and server developers to focus on their preferred
108+
area of specialization.</p>
109+
</li>
110+
<li>
111+
<p><strong>WSGI servers promote scaling</strong>. Serving thousands of requests for dynamic
112+
content at once is the domain of WSGI servers, not frameworks.
113+
WSGI servers handle processing requests from the web server and deciding
114+
how to communicate those requests to an application framework's process.
115+
The segregation of responsibilities is important for efficiently scaling
116+
web traffic.</p>
117+
</li>
118+
</ul>
119+
<p>WSGI is by design a simple standard interface for running Python code. As
120+
a web developer you won't need to know much more than</p>
121+
<ul>
122+
<li>
123+
<p>what WSGI stands for (Web Server Gateway Inteface)</p>
124+
</li>
125+
<li>
126+
<p>that a WSGI container is a separate running process that runs on a
127+
different port than your web server</p>
128+
</li>
129+
<li>
130+
<p>your web server is configured to pass requests to the WSGI container which
131+
runs your web application, then pass the response (in the form of HTML)
132+
back to the requester</p>
133+
</li>
134+
</ul>
135+
<p>If you're using a standard web framework such as Django, Flask, or
136+
Bottle, or almost any other current Python framework, you don't need to worry
137+
about how frameworks implement the application side of the WSGI standard.
138+
Likewise, if you're using a standard WSGI container such as Green Unicorn,
139+
uWSGI, mod_wsgi, or gevent, you can get them running without worrying about
140+
how they implement the WSGI standard.</p>
141+
<p>However, knowing the WSGI standard and how these frameworks and containers
142+
implement WSGI should be on your learning checklist though as you become
143+
a more experienced Python web developer.</p>
144+
<h2>Official WSGI specifications</h2>
96145
<p>The WSGI standard v1.0 is specified in
97146
<a href="http://www.python.org/dev/peps/pep-0333/">PEP 0333</a>. As of September 2010,
98147
WSGI v1.0 is superseded by
@@ -142,55 +191,6 @@ <h2>Example configuration</h2>
142191
<p>Note that the above code is a simplified version of a production-ready Nginx
143192
configuration. For real SSL and non-SSL templates, take a look at the
144193
<a href="https://github.com/makaimc/underwear/tree/master/underwear/roles/web/templates">Underwear web server templates</a> on GitHub.</p>
145-
<p>WSGI is by design a simple standard interface for running Python code. As
146-
a web developer you won't need to know much more than</p>
147-
<ul>
148-
<li>
149-
<p>what WSGI stands for (Web Server Gateway Inteface)</p>
150-
</li>
151-
<li>
152-
<p>that a WSGI container is a separate running process that runs on a
153-
different port than your web server</p>
154-
</li>
155-
<li>
156-
<p>your web server is configured to pass requests to the WSGI container which
157-
runs your web application, then pass the response (in the form of HTML)
158-
back to the requester</p>
159-
</li>
160-
</ul>
161-
<p>If you're using a standard web framework such as Django, Flask, or
162-
Bottle, or almost any other current Python framework, you don't need to worry
163-
about how frameworks implement the application side of the WSGI standard.
164-
Likewise, if you're using a standard WSGI container such as Green Unicorn,
165-
uWSGI, mod_wsgi, or gevent, you can get them running without worrying about
166-
how they implement the WSGI standard.</p>
167-
<p>However, knowing the WSGI standard and how these frameworks and containers
168-
implement WSGI should be on your learning checklist though as you become
169-
a more experienced Python web developer.</p>
170-
<h2>WSGI's Purpose</h2>
171-
<p>Why use WSGI and not just point a web server directly at an application?</p>
172-
<ul>
173-
<li>
174-
<p><strong>WSGI gives you flexibility</strong>. Application developers can swap out
175-
web stack components for others. For example, a developer can switch from
176-
Green Unicorn to uWSGI without modifying the application or framework
177-
that implements WSGI.
178-
From <a href="http://www.python.org/dev/peps/pep-3333/">PEP 3333</a>:</p>
179-
<p>The availability and widespread use of such an API in web servers for
180-
Python [...] would separate choice of framework from choice of web
181-
server, freeing users to choose a pairing that suits them, while
182-
freeing framework and server developers to focus on their preferred
183-
area of specialization.</p>
184-
</li>
185-
<li>
186-
<p><strong>WSGI servers promote scaling</strong>. Serving thousands of requests for dynamic
187-
content at once is the domain of WSGI servers, not frameworks.
188-
WSGI servers handle processing requests from the web server and deciding
189-
how to communicate those requests to an application framework's process.
190-
The segregation of responsibilities is important for efficiently scaling
191-
web traffic.</p>
192-
</li>
193-
</ul>
194194
<h2>WSGI Resources</h2>
195195
<ul>
196196
<li>

0 commit comments

Comments
 (0)