20 ms·

This. There was recently a trendy thread on HN about how great CGI was. WSGI is basically one of the spiritual successors to CGI: it's a simple way for a web s

This. There was recently a trendy thread on HN about how great CGI was. WSGI is basically one of the spiritual successors to CGI: it's a simple way for a web server and a Python application to interact. It addresses one of the major shortcomings of CGI by not requiring to launch a new process for every request. 20 years later it is still going strong and is still by far the main way Python web apps are served.

assume_role 4y ago
Do python mains not know what FastCGI or mod_python are?
- nicolaslem 4y ago
  WSGI and mod_wsgi were designed as an improvement over mod_python which was pretty much an Apache only thing. As for FastCGI, although it is language agnostic it didn't really get traction outside of PHP.
  - uranusjr 4y ago
    WSGI (same for ASGI) is a level above FastCGI (or CGI or whatever) in the stack; it exists so each Python web framework does not need implement ways to talk to CGI, FastCGI or whatever. Instead the framework implements a Python function, and the user can choose a WSGI server to wrap this Python function into whatever is needed to talk to any kind of language-agnostic gateways, including CGI, FastCGI, or even mod_python.
    - nicolaslem 4y ago
      In practice most deployments I have seen use a WSGI server that directly speaks HTTP so that CGI, FastCGI, or mod_python are not even necessary.
- linsomniac 4y ago
  mod_python is pretty much dead at this point. Ubuntu 22.04 ships a port of it to Python 3, but it is buggy. I ended up switching my code from mod_python to WSGI instead of debugging "apache segfaulting in mod_python" issues, on some ~20 year old mod_python code over the last year. Pro tip: WSGI is pronounced like "whiskey". :-)
  - aidos 4y ago
    Is it?? I’ve been slaughtering that word for almost 15 years. Whether true or not, that’s what I’m calling it from now on.
    - linsomniac 4y ago
      Ian Bicking is the one who told me, so I feel like I can speak with some authority. :-)
- masklinn 4y ago
  layer below and dead, respectively. The point of WSGI is for the server and application to speak the same python-level protocol. You can have a wsgi adapter on top of fcgi, though it’s really a waste of resources if you can skip fcgi entirely (which you usually can).
- simonw 4y ago
  I have a loos story I can tell that links mod_python to WSGI (a bit). One of the initial inspirations for creating the Django web framework back a the Lawrence Journal-World newspaper in ~2003 was that we wanted to start using Python on the web, but were concerned that mod_python didn't have quite enough existing users. What if it turned out not to work for us? So we designed a simple abstraction layer - a request and response object - as an insurance policy. If mod_python turned out not to work for us we could switch to something else without having to rewrite all of our code. At around about the same time the Python Web SIG formed - https://simonwillison.net/2003/Oct/18/pythonWebSIG/ https://simonwillison.net/2003/Oct/18/pythonWebSIG/ - and we joined it with the aim of helping define a standard similar to what we had been building for our own, private newspaper CMS. WSGI was the eventual result of that SIG - I didn't participate in the working group nearly as actively as I had planned to, so I can't say that I had much if any impact on the result. But hopefully this illustrates that yes, the people involved were very aware of mod_python back in 2003 when this work kicked off.
  - whatever1 4y ago
    Thank you so much for your work! It really shaped a generation of web development, giving a shot to small players and startups. PS That is why I love HN. You get to casually see creators of great projects.
- john-radio 4y ago
  Speaking on behalf of the basic python main community, we just do whatever `requests` does.
  - panzi 4y ago
    That's a HTTP client library.
laurencerowe 4y ago
One of the nice things about CGI was that by starting a new process per request it provided isolation between requests. Python's startup overhead obviously makes CGI untenable, but I find the new Web Assembly runtimes interesting because they are able to provide extremely fast startup by reseting state: https://bytecodealliance.org/articles/wasmtime-10-performance https://bytecodealliance.org/articles/wasmtime-10-performanc...
- nine_k 4y ago
  PHP was built around this idea for decades %) Theoretically one could produce ready-to-run, guaranteed clean Python request handlers very quickly. Run all the startup and imports stuff in a Python process, then freeze it. Fork a copy of it on a new request (with COW it's definitely fast), and terminate it normally after that. This would require some care, e.g. to not open sockets before the fork, so that handlers won't share it. I bet it has been tried, but I'm too lazy to actually search for that.
  - laurencerowe 4y ago
    Forking can be quite slow (milliseconds), though there are techniques to speed it up: https://www.cs.purdue.edu/homes/pfonseca/papers/eurosys21-odf.pdf https://www.cs.purdue.edu/homes/pfonseca/papers/eurosys21-od... I believe wasmtime can be faster as it doesn’t need to create as many new OS resources and just resets some memory maps. Only really meaningful for simple request handlers taking a few milliseconds.
    - grubby 4y ago
      boiler up
neilv 4y ago
The thread: "The beauty of CGI and simple design (rubenerd.com)" | 320 points by susam 9 days ago | 215 comments | https://news.ycombinator.com/item?id=34286622 https://news.ycombinator.com/item?id=34286622

assume_role 4y ago

Do python mains not know what FastCGI or mod_python are?

nicolaslem 4y ago
WSGI and mod_wsgi were designed as an improvement over mod_python which was pretty much an Apache only thing. As for FastCGI, although it is language agnostic it didn't really get traction outside of PHP.
- uranusjr 4y ago
  WSGI (same for ASGI) is a level above FastCGI (or CGI or whatever) in the stack; it exists so each Python web framework does not need implement ways to talk to CGI, FastCGI or whatever. Instead the framework implements a Python function, and the user can choose a WSGI server to wrap this Python function into whatever is needed to talk to any kind of language-agnostic gateways, including CGI, FastCGI, or even mod_python.
  - nicolaslem 4y ago
    In practice most deployments I have seen use a WSGI server that directly speaks HTTP so that CGI, FastCGI, or mod_python are not even necessary.
linsomniac 4y ago
mod_python is pretty much dead at this point. Ubuntu 22.04 ships a port of it to Python 3, but it is buggy. I ended up switching my code from mod_python to WSGI instead of debugging "apache segfaulting in mod_python" issues, on some ~20 year old mod_python code over the last year. Pro tip: WSGI is pronounced like "whiskey". :-)
- aidos 4y ago
  Is it?? I’ve been slaughtering that word for almost 15 years. Whether true or not, that’s what I’m calling it from now on.
  - linsomniac 4y ago
    Ian Bicking is the one who told me, so I feel like I can speak with some authority. :-)
masklinn 4y ago
layer below and dead, respectively. The point of WSGI is for the server and application to speak the same python-level protocol. You can have a wsgi adapter on top of fcgi, though it’s really a waste of resources if you can skip fcgi entirely (which you usually can).
simonw 4y ago
I have a loos story I can tell that links mod_python to WSGI (a bit). One of the initial inspirations for creating the Django web framework back a the Lawrence Journal-World newspaper in ~2003 was that we wanted to start using Python on the web, but were concerned that mod_python didn't have quite enough existing users. What if it turned out not to work for us? So we designed a simple abstraction layer - a request and response object - as an insurance policy. If mod_python turned out not to work for us we could switch to something else without having to rewrite all of our code. At around about the same time the Python Web SIG formed - https://simonwillison.net/2003/Oct/18/pythonWebSIG/ https://simonwillison.net/2003/Oct/18/pythonWebSIG/ - and we joined it with the aim of helping define a standard similar to what we had been building for our own, private newspaper CMS. WSGI was the eventual result of that SIG - I didn't participate in the working group nearly as actively as I had planned to, so I can't say that I had much if any impact on the result. But hopefully this illustrates that yes, the people involved were very aware of mod_python back in 2003 when this work kicked off.
- whatever1 4y ago
  Thank you so much for your work! It really shaped a generation of web development, giving a shot to small players and startups. PS That is why I love HN. You get to casually see creators of great projects.
john-radio 4y ago
Speaking on behalf of the basic python main community, we just do whatever `requests` does.
- panzi 4y ago
  That's a HTTP client library.

laurencerowe 4y ago

One of the nice things about CGI was that by starting a new process per request it provided isolation between requests. Python's startup overhead obviously makes CGI untenable, but I find the new Web Assembly runtimes interesting because they are able to provide extremely fast startup by reseting state: https://bytecodealliance.org/articles/wasmtime-10-performance https://bytecodealliance.org/articles/wasmtime-10-performanc...

nine_k 4y ago
PHP was built around this idea for decades %) Theoretically one could produce ready-to-run, guaranteed clean Python request handlers very quickly. Run all the startup and imports stuff in a Python process, then freeze it. Fork a copy of it on a new request (with COW it's definitely fast), and terminate it normally after that. This would require some care, e.g. to not open sockets before the fork, so that handlers won't share it. I bet it has been tried, but I'm too lazy to actually search for that.
- laurencerowe 4y ago
  Forking can be quite slow (milliseconds), though there are techniques to speed it up: https://www.cs.purdue.edu/homes/pfonseca/papers/eurosys21-odf.pdf https://www.cs.purdue.edu/homes/pfonseca/papers/eurosys21-od... I believe wasmtime can be faster as it doesn’t need to create as many new OS resources and just resets some memory maps. Only really meaningful for simple request handlers taking a few milliseconds.
  - grubby 4y ago
    boiler up

neilv 4y ago

The thread: "The beauty of CGI and simple design (rubenerd.com)" | 320 points by susam 9 days ago | 215 comments | https://news.ycombinator.com/item?id=34286622 https://news.ycombinator.com/item?id=34286622