¿Cuál es el punto de uWSGI?

Estoy mirando la especificación WSGI y estoy tratando de averiguar cómo encajan los servidores como uWSGI en 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 con Flask . Lo que no entiendo es para qué sirve uWSGI. ¿Por qué nginx no puede llamar directamente a mi aplicación Flask? ¿No puede flask hablar WSGI directamente con él? ¿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?

Bien, creo que lo entiendo ahora.

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

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

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

Tenga en cuenta que uWSGIes un servidor http completo que puede funcionar 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 quedarse nginxfrente a su uWSGIservidor. Cuando lo haga, se comunicarán a través de un protocolo de bajo nivel conocido como uwsgi.

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

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

NGINX en este caso solo funciona como un proxy inverso y procesa archivos estáticos, no archivos dinámicos , 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. De hecho, 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 documentos :

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 dice qué métodos deben implementarse para pasar solicitudes y respuestas entre el servidor y la aplicación. Cuando se utilizan marcos como Flask o Django, esto lo maneja el marco mismo.

En otras palabras, WSGI es básicamente un contrato entre aplicaciones de 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 indica 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 de marco web limitará su elección de servidores web utilizables y viceversa.

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

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

En términos simples, solo piense en una analogía en la que está ejecutando una aplicación CGI o PHP con el servidor web Nginx. Utilizará los controladores respectivos como php-fpm para ejecutar estos archivos, ya que el servidor web, en su forma nativa, no procesa estos formatos.