tiangolo python nginx flask wsgi uwsgi

python - tiangolo - uwsgi flask



¿Cuál es el punto de uWSGI? (3)

Estoy mirando la especificación WSGI y estoy tratando de descubrir cómo los servidores como uWSGI ajustan a la imagen. Entiendo que el objetivo de la especificación WSGI es separar los servidores web como nginx de las aplicaciones web como algo que escribirías usando Flask . Lo que no entiendo es para qué sirve uWSGI. ¿Por qué nginx no puede llamar directamente a mi aplicación Flask? ¿No puede el matraz hablarle WSGI directamente? ¿Por qué uWSGI necesita interponerse entre ellos?

Hay dos lados en la especificación WSGI: el servidor y la aplicación web. ¿De qué lado está uWSGI?


De acuerdo, creo que entiendo esto ahora.

¿Por qué nginx no puede llamar directamente a mi aplicación Flask?

Porque nginx no es compatible con la especificación WSGI. Técnicamente, nginx podría implementar la especificación WSGI si quisieran, simplemente no lo han hecho.

Siendo ese el caso, necesitamos un servidor web que implemente la especificación, que es para lo que uWSGI servidor uWSGI .

Tenga en cuenta que uWSGI es un servidor http completo que puede y funciona bien por sí solo. Lo he usado en esta capacidad varias veces y funciona muy bien. Si necesita un rendimiento súper alto para contenido estático, entonces tiene la opción de pegar nginx frente a su servidor uWSGI . Cuando lo haga, se comunicarán a través de un protocolo de bajo nivel conocido como uwsgi .

"¡¿Qué, qué ?! ¡¿Otra cosa llamada uwsgi ?!" usted pregunta. Si, es confuso. Cuando hace referencia a uWSGI , está hablando de un servidor http. Cuando habla de uwsgi (todo en minúsculas) está hablando de un protocolo binario que el servidor uWSGI usa para hablar con otros servidores como nginx . Escogieron un mal nombre en este caso.

Para cualquiera que esté interesado, escribí un artículo de blog sobre él con más detalles, un poco de historia y algunos ejemplos.


NGINX en este caso solo funciona como un proxy inverso, recibe las solicitudes y las envía al servidor de aplicaciones, que sería UWSGI.

El servidor UWSGI es responsable de cargar su aplicación Flask usando la interfaz WSGI. En realidad, puede hacer que UWSGI escuche directamente las solicitudes de Internet y eliminar NGINX si lo desea, aunque se usa principalmente detrás de un proxy inverso.

De los docs :

uWSGI admite varios métodos de integración con servidores web. También es capaz de atender solicitudes HTTP por sí mismo.

WSGI es solo una especificación de interfaz, en términos simples, le indica qué métodos deben implementarse para pasar solicitudes y respuestas entre el servidor y la aplicación. Cuando se usan frameworks como Flask o Django, esto es manejado por el propio framework.

En otras palabras, WSGI es básicamente un contrato entre aplicaciones python (Flask, Django, etc.) y servidores web (UWSGI, Gunicorn, etc.). El beneficio es que puede cambiar los servidores web con poco esfuerzo porque sabe que cumplen con la especificación WSGI, que en realidad es uno de los objetivos, como se establece en PEP-333 .

Python actualmente cuenta con una amplia variedad de marcos de aplicaciones web, como Zope, Quixote, Webware, SkunkWeb, PSO y Twisted Web, por nombrar solo algunos [1]. Esta amplia variedad de opciones puede ser un problema para los nuevos usuarios de Python, porque, en términos generales, su elección del marco web limitará su elección de servidores web utilizables, y viceversa.


Un servidor web tradicional no entiende o no tiene forma de ejecutar aplicaciones Python. Es por eso que entra el servidor WSGI. Por otro lado, Nginx admite proxy inverso para manejar solicitudes y devolver respuestas para servidores Python WSGI.

Este enlace puede ayudarlo: https://www.fullstackpython.com/wsgi-servers.html