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 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]> 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]> > >> 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]> >> >>> 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]. >>> 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. >>> >> >> -- >> 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. >> >> >> -- >> 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. >> > > -- > 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. > -- 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.
