45 ms·

I did some Django years ago and if I remember correctly Django wasn't a "server" ie long running process but more like CGI. So how does it work exactly ? is the

I did some Django years ago and if I remember correctly Django wasn't a "server" ie long running process but more like CGI. So how does it work exactly ? is there some python code running as a demon polling socket events and interacting with the actual Django app ?

nostrademons 11y ago
Django is agnostic about its actual connection to the webserver. It provides a basic wsgi adapter (wsgi is the Python spec for delivering HTTP requests to an app and sending responses back to the client), which can be plugged into any wsgi container. When HTTP requests arrive at the wsgi container, it forwards them on to Django's entry point, which runs the normal routes/views/middleware/etc. When I first got into Django in 2007 the preferred container was flup, using an scgi connection to the webserver. Nowadays, it seems like uwsgi over HTTP is preferred. CGI was an option for deployment since inception, but I don't know anyone that actually ran their Django apps over CGI, since it's many times slower than using uwsgi. Django Channels extends wsgi into asgi (ASynchronous Gateway Interface), which provides both send() and receive_many() callables to the application server. In other words, Django can now send messages, unsolicited, back to the webserver, which presumably has a websocket connection back to the browser.
samcheng 11y ago
Django generally relies on the WSGI standard to separate the 'server' from the (Django) 'application' - this allows Django to run on a number of different server implementations. https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface
deleted 11y ago
[deleted]
ubernostrum 11y ago
The underlying model for all Python Web apps -- WSGI -- is CGI-like. But the actual deployment of WSGI almost always involves a long-running process or processes, which keep the application code in memory and then expose the appropriate WSGI API to whatever Web server you're using. Switching that from "expose WSGI API" to "expose ASGI API" gets you Channels :)

nostrademons 11y ago

Django is agnostic about its actual connection to the webserver. It provides a basic wsgi adapter (wsgi is the Python spec for delivering HTTP requests to an app and sending responses back to the client), which can be plugged into any wsgi container. When HTTP requests arrive at the wsgi container, it forwards them on to Django's entry point, which runs the normal routes/views/middleware/etc. When I first got into Django in 2007 the preferred container was flup, using an scgi connection to the webserver. Nowadays, it seems like uwsgi over HTTP is preferred. CGI was an option for deployment since inception, but I don't know anyone that actually ran their Django apps over CGI, since it's many times slower than using uwsgi. Django Channels extends wsgi into asgi (ASynchronous Gateway Interface), which provides both send() and receive_many() callables to the application server. In other words, Django can now send messages, unsolicited, back to the webserver, which presumably has a websocket connection back to the browser.

samcheng 11y ago

Django generally relies on the WSGI standard to separate the 'server' from the (Django) 'application' - this allows Django to run on a number of different server implementations. https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface

deleted 11y ago

[deleted]

ubernostrum 11y ago

The underlying model for all Python Web apps -- WSGI -- is CGI-like. But the actual deployment of WSGI almost always involves a long-running process or processes, which keep the application code in memory and then expose the appropriate WSGI API to whatever Web server you're using. Switching that from "expose WSGI API" to "expose ASGI API" gets you Channels :)