Buscando un diagtwig para explicar WSGI

Para ayudar a comprender mejor WSGI, estoy buscando un diagtwig que explique el flujo de una aplicación, desde el servidor web (por ejemplo, apache) a través de varios middlewares hasta “codificar” (como en el bit de print "hello world" ) .

He leído varios artículos relacionados con WSGI de wsgi.org, pero aún así no es un “clic” para mí y para los diagtwigs. Google no está devolviendo nada útil excepto esto para django que, aunque es interesante, espera que el usuario entienda cómo enlaces de middleware y tal.

Dado que “una imagen vale más que mil palabras”, ¿hay diagtwigs por ahí que sean un poco más bajos / más simplistas que esto?

También he estado buscando un diagtwig que explique el flujo de WSGI durante algún tiempo. Por eso me sentí muy feliz cuando encontré este tema. Tenía grandes expectativas de lo que iba a ver sabiendo lo bueno que es Ian Bicking al escribir Python. Sin embargo, literalmente no gané nada mirando los tubos de fantasía de Ian (¿diagtwig?). Por eso decidí dibujar uno yo mismo. Espero que ayude a alguien a entender cómo funciona el flujo de WSGI. Mientras tenga sugerencias sobre cómo mejorarlo, estoy abierto a modificarlo. Fue creado con la aplicación web LUCIDCHART . El diagtwig original que puede encontrar aquí y el PNG de alta calidad está aquí .

Flujo WSGI

Me gusta el diagtwig de WSGI de Ian Bicking – Una serie de tubos .

No sé si puedo proporcionarle la respuesta que está buscando, pero el diagtwig al que está vinculado muestra más que solo wsgi. La capa wsgi termina en la segunda línea del diagtwig. Después de eso es la aplicación específica.

WSGI es más una definición de interfaz o un contrato que se reduce a proporcionar de alguna manera una función que toma un diccionario (environ) que representa el contenido de la solicitud actual. y una función para llamar cuando esté listo para iniciar la respuesta (start_response).

El método start_response al que llama necesita un código de estado HTTP (‘200 OK’) y una lista de encabezados HTTP ([(‘tipo de contenido’, ‘texto / html’)]).

 def say_hello(envron={},start_response): start_response('200 OK', [('content-type', 'text/html')]) return ["Hello from WSGI"] 

La conexión de su servidor web a su aplicación wsgi es específica de su servidor web. Creo que la información sobre cómo llega el servidor web al diccionario del entorno y una callback para su código es la magia del servidor web que probablemente no deba preocuparle. . Y mientras cumpla con el protocolo, el servidor web no tiene que preocuparse por cómo llegó a su lista de resultados que constituye su respuesta desde su aplicación.

La documentación de pegar me ayudó mucho. Lo podrías encontrar útil. Por cierto, Pegar es un conjunto de cosas útiles que lo ayudan a utilizar WSGI. Y los documentos son muy buenos para entender cómo usar WSGI y, por extensión, Pegar.

Sé que pediste un diagtwig lo siento. 🙁