The word "simple" appears 13 times in PEP3333, but no one knows how this magical specification works? Can anyone confirm I'm not crazy please?
On Tuesday, February 26, 2019 at 3:13:00 PM UTC-7, Tal wrote: > > Is it right though? > > On Tuesday, February 26, 2019 at 2:49:03 PM UTC-7, mike wrote: >> >> Great write up! >> >> On Tue, Feb 26, 2019 at 2:39 PM Tal <tal....@gmail.com> wrote: >> >>> Did I get something wrong? >>> Do you mean the devs working on the Django project know nothing about >>> this, or the devs using Django to build web apps? >>> From what I've read, devs using Django don't need to be too familiar >>> with WSGI, but it seems like it helps at least having a conceptual >>> understanding of what it is. >>> >>> On Tuesday, February 26, 2019 at 12:28:26 PM UTC-7, Motaz Hejaze wrote: >>>> >>>> You are very close to what realy happens , most of devs know nothing >>>> aboutbthis stuff >>>> >>>> On Tue, 26 Feb 2019, 20:26 Tal, <tal....@gmail.com> wrote: >>>> >>>>> I've been developing web applications using Flask and Django for about >>>>> a year now, and although I've come across the term WSGI a bunch of times >>>>> in >>>>> both frameworks, I never really understood what it did. I'm sure I'm not >>>>> the only one. The quick explanations I read never made sense to me. Even >>>>> PEP3333 didn't really give me a clear picture of how WSGI fits in with >>>>> Nginx, and Django. There are a bunch of articles online that quickly show >>>>> how to setup nginx, gunicorn/uwsgi and django to work in production, and >>>>> once I figured that out, I never really had a reason to figure out WSGI >>>>> again. But it's been a year now, and I probably should understand at >>>>> least >>>>> the basics. >>>>> >>>>> I did a bit more reading recently, and I think I get it. Just looking >>>>> for someone to confirm that I'm on the right track. >>>>> This is how I think it works: >>>>> >>>>> My example uses the most common setup I use: Nginx, Gunicorn and Django >>>>> >>>>> - When an HTTP request comes in, it hits Nginx first >>>>> - Nginx runs multiple processes, and makes sure that >>>>> browsers/clients that have a slow connection don't effect other >>>>> clients >>>>> - If it's a request for a static file, like a CSS file, JS, >>>>> image, or anything like that, Nginx returns it directly >>>>> - If it's a request for anything else, it uses *HTTP* to send >>>>> the request over a Unix socket to Gunicorn >>>>> - Doesn't have to be a Unix socket, but if both Nginx and >>>>> Gunicorn are running on the same host, it makes sense to use >>>>> Unix sockets >>>>> - The main point is that Nginx uses HTTP to communicate with >>>>> Gunicorn >>>>> - Gunicorn >>>>> - Starts up x worker processes on startup (as many as you tell >>>>> it) >>>>> - Each worker process imports your application's code >>>>> (django.core.wsgi.get_wsgi_application() in Django's case) >>>>> - The application's code is a callable function >>>>> - Gunicorn imports it so that it's ready to make a function >>>>> call to it as soon as an HTTP request comes in >>>>> - When an HTTP request comes in from Nginx, Gunicorn will: >>>>> - Use its main process to assign the request to a free >>>>> worker process >>>>> - The worker process translates the HTTP headers into a >>>>> python dictionary (commonly called the 'environment' dictionary) >>>>> - The worker process makes a function call to your >>>>> application, passing it the 'environment' dictionary, and a >>>>> start_response >>>>> function >>>>> - When your application (Django) decides what to do about the >>>>> request, and decides to formulate a response, it will: >>>>> - Call start_response, giving it the HTTP response status (eg. >>>>> 200 OK), and the HTTP response headers as a Python object (list of >>>>> tuples) >>>>> - Note: At this point, nothing is sent to the client's browser, >>>>> or even Nginx yet >>>>> - *Return* the body of the response as an iterable >>>>> - Gunicorn will then: >>>>> - Add any required HTTP headers the application didn't provide >>>>> - Turn the status, headers and body that it received from the >>>>> application into an HTTP response message >>>>> - Send the response back to Nginx using HTTP >>>>> - Nginx will then send the response back to the client >>>>> >>>>> >>>>> So the job of the individual parts is basically this: >>>>> >>>>> 1. Nginx >>>>> - Buffers slow clients >>>>> - Quickly serves static files >>>>> - Possibly handle SSL, if configured >>>>> - Passes HTTP requests to Gunicorn (also using HTTP) >>>>> 2. Gunicorn >>>>> - Deals with TCP connections between nginx and itself >>>>> - Prevents your application from needing to do lower-level >>>>> socket stuff with TCP >>>>> - Converts HTTP requests into Python objects, and responses >>>>> back into HTTP >>>>> 3. Django >>>>> - Just worries about formulating responses to requests, not >>>>> keeping track of TCP connections, or HTTP, or anything low-level >>>>> >>>>> >>>>> For Apache, they have mod_wsgi, which takes the place of Gunicorn, >>>>> acting as a WSGI server. >>>>> >>>>> That sound right? Or am I way off? >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Django users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to django-users...@googlegroups.com. >>>>> To post to this group, send email to django...@googlegroups.com. >>>>> Visit this group at https://groups.google.com/group/django-users. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/django-users/77576c51-8237-46b1-bd48-8f30bbaea3bf%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/django-users/77576c51-8237-46b1-bd48-8f30bbaea3bf%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-users...@googlegroups.com. >>> To post to this group, send email to django...@googlegroups.com. >>> Visit this group at https://groups.google.com/group/django-users. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-users/f25e3afa-64dc-4d3e-b546-e0352cfcd5d1%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-users/f25e3afa-64dc-4d3e-b546-e0352cfcd5d1%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/a16dad62-5864-4a20-bc89-24d70f68a37c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
