Steven, I'll try a different approach in describing this, maybe it'll
help. I often find if I explain something to my wife, it suddenly
makes a lot more sense to me! Plus, with my morning coffee I try to
do something fun, so today it's my own twisted version of "web tech
history". :-)
HTTP (HyperText Transfer Protocol) was originally designed to deliver
static text content from a server to a browser. Basically, the
original web server was nothing more than a bit of code that read
files off the drive and delivered them over the TCP/IP protocol to a
client capable of rendering html markup to the user. Although it's
evolved since then, at their core tools like Apache and nginx are http
servers, basically fulfilling the same role.
Since the original browsers didn't have Javascript, developers
immediately realized static content wasn't good enough. Rather than
hack up the web server with tons of new features and bloat, the
designers rightly decided to keep the server simple, and allow
external extensions via a standard interface. The common gateway
interface (CGI) was born. Using CGI, a web server could "hand off" a
request to an external program (written in almost any language). That
external program will do it's magic, and hand the result back to the
http server, which will deliver the content to the browser.
Basically, it stuck a plugin in place of reading a static file,
allowing dynamic files.
CGI, while a quick fix to the problem, eventually sort of died under
the weight of it's inherent problems. Each request had to fire off a
process, therefore performance was slow. Each of the leading http
servers came up with their own replacement for CGI. (Apache modules,
NSAPI and ISAPI plugins, etc.) The industry fractured into turf wars
about the best way to do server side code.
Things have never really settled down, many alternate ways to do
server side code are available, from ASP.NET <http://ASP.NET> to PHP,
each one communicating with the server using an interface that was an
evolution of CGI.
Finally, WSGI is a semi-unique beast. Python initially lost some
ground as a web programming language, as the choice of servers and
interfaces was limited. Code could be hooked to a few web servers
using CGI, FastCGI, or an Apache module called mod_python, all
arguably suboptimal in some regard. Enter WSGI - a "middleware"
between a python framework and any web server willing to implement an
interface. WSGI is the best way to build web services using python,
as it provides the richest interaction between python code and an http
server.
(Web.py has implemented a wsgi interface, meaning you can technically
hook it to any server that supports wsgi. Apache and nginx are the
favorites.)
There was an explosion of frameworks in the early 2000s to help
developers dynamically build static pages, loaded with widgets, tools
and "best practices". Confusion, showboating and religious wars
abound to this day.
"Web 2.0" also came along in the early 2000's, and using ajax and
javascript, the web applications with the richest user experience now
make far less use of server side processing, offloading a lot of the
logic to the browser. The big frameworks have struggled to integrate
client side code into their models, as the browser is "outside their
sandbox".
We've come full circle - now that the leading browsers (yes, even
IE9/10) are pretty consistent, it's easy to distribute the work out to
the clients and build really powerful web applications. This has (to
a degree) reduced the load on the web server - where once you'd build
complex server side logic to create and serve a static page, now
that's shift(ing/ed) to serving /data/ to the browsers and letting
them build the visible content.
Which is why web.py is my favorite - it doesn't presume to tell me the
best way to do anything - I get to decide. I can generate my pages in
python code, or I can deliver JSON to the browser and render it using
javascript, or I can build a REST API interface on a legacy
application, and I can do any of these with or without an external web
server.
My coffee is done, and so am I. If this helped anyone, cheers. If it
didn't, ignore it!
S
Final thought - why do you feel you "need" to use an external web
server? We have four applications, all just use the built-in server,
and all serve tens of thousands of requests per day. There are
certainly many valid reasons to use an external server, just keep it
simple if you can. :-)
On Thu, Dec 12, 2013 at 6:41 AM, Joey Chang <[email protected]
<mailto:[email protected]>> wrote:
I think you should start from CGI.
http://en.wikipedia.org/wiki/Common_Gateway_Interface .
*Common Gateway Interface* (*CGI*) is a standard method used to
generate *dynamic content on web pages and web applications
<http://en.wikipedia.org/wiki/Web_applications>*.
CGI provides an interface between the web server and programs that
generate the web content. OK, the web server is like nginx or
apache things, and the the programs which generate the web content
like web frameworks. We call web application.
So, we can draw a request/response line stream below:
--------------------------- request
-----||---------handle------||---- response -----------------------
Client -> web server -> cgi -> web application -> cgi -> web
server -> client
wsgi is a protocol like cgi but more advanced which implemented by
python.
uwsgi is like more advanced cgi, too, which can be implemented by
lots of languages (i.e. python, lua ).
And how these things work together? Only just set the right
parameters in their conf files (containing log set), which you can
google.
Maybe, my description is not clear, wish would help you.
2013/12/12 Steven Brown <[email protected]
<mailto:[email protected]>>
Thanks. I looked over the web.py section of that link; there
wasn't a lot there. For one thing, nothing at all about
nginx. Now I probably should have mentioned that I'm very new
to web programming, so a good number of things that may be
obvious to others won't be to me. So....what *is* uwsgi? Is
it the same as wsgi? In the example given, where do the
logs/stderr/stdout go? And does the example use nginx,
somewhere under the hood, or what? I guess my major confusion
stems from the fact that I thought web.py as a web framework,
has everything you need. It has certainly served webpages for
me. I thought it was basically a replacement for i.e.
Apache? Or is the server separate from the framework? Is the
framework just in charge of generating pages, and the server
actually delivers them? nginx seems to be a server, in
addition to other stuff I don't know what it does, but then
what does uwsgi/wsgi actually do? The WSGI homepage says it's
a full stack for building hosting services. I don't know what
that means :P
On 12/10/2013 10:47 PM, Joey Chang wrote:
webpy + uwsgi + nginx
http://projects.unbit.it/uwsgi/wiki/Example
It's simple and convenient.
2013/12/11 Steven Brown <[email protected]
<mailto:[email protected]>>
Hi everyone, it's been quiet for a while on the list! I
am trying to do my servers the Right Way, but I'm not
sure what I should/need to do. First, I want to properly
daemonize my server. I have been doing something like
nohup python myServer.py 1234 &
but I'm not sure if that really covers everything. I
feel like there's some "official" way to make a process a
daemon, that does everything correctly, but I'm not sure
what it could be! That way is also not so good with
logging; I want to send all my stdout and stderr to a log
file, or 2 log files, if that can happen. Doing it on
the command line with > redirects hasn't really worked,
and I feel like that's not what I should be doing anyway.
And then there is the Deployment section on the website,
but I'm not sure if I actually need any of that...I mean,
I don't get why I need to use Apache, for example.
web.py works out of the box, so what would I add yet
another program to my stack for? But, I do want to do
things right, so if I need to use Apache or whatever I
will; but then, I don't know how to make a decision on
which method to use....
Overall, the documentation is just a bit fragmented, and
I'm not sure how to pull out what I need. Can anyone
offer some insight?
--
You received this message because you are subscribed to
the Google Groups "web.py" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to
[email protected]
<mailto:webpy%[email protected]>.
To post to this group, send email to
[email protected] <mailto:[email protected]>.
Visit this group at http://groups.google.com/group/webpy.
For more options, visit
https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the
Google Groups "web.py" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to [email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at http://groups.google.com/group/webpy.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the
Google Groups "web.py" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to [email protected]
<mailto:webpy%[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at http://groups.google.com/group/webpy.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google
Groups "web.py" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected]
<mailto:webpy%[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at http://groups.google.com/group/webpy.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google
Groups "web.py" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/webpy.
For more options, visit https://groups.google.com/groups/opt_out.
