Si trabajas con Python y necesitas exponer tu aplicación en la web, entender WSGI y ASGI es lo que separa un deploy que funciona de uno que se cae bajo carga. Aquí verás qué son, cómo se diferencian y cuándo elegir cada uno con un ejemplo en código.

¿Qué es WSGI y por qué Python lo necesita?

Python no devuelve HTML por sí mismo. Cuando ejecutas una aplicación, lo que obtienes es un output que el servidor web tiene que interpretar. Ahí entra el protocolo que actúa como puente entre tu código y el servidor.

WSGI (Web Server Gateway Interface) es el estándar tradicional: recibe un request, genera un response y lo retorna al servidor para que lo muestre. Funciona de forma síncrona, es decir, una solicitud a la vez por proceso.

¿Qué es WSGI en Python? Es el protocolo estándar que conecta aplicaciones Python síncronas con servidores web. Recibe un request, lo procesa y devuelve la respuesta al servidor.

¿Cómo se ve una aplicación WSGI mínima?

En el ejemplo se crea un archivo wsgi_app.py con una función app que recibe environment y start_response. Esa función define el status, los headers y retorna el contenido en bytes.

python def app(environment, start_response): status = "200 OK" headers = [("Content-Type", "text/plain; charset=UTF-8")] start_response(status, headers) return [b"Hello WSGI World"]

Para ejecutarlo se usa Gunicorn, una librería que se instala con pip install gunicorn y que permite levantar la aplicación con varios workers en paralelo.

bash gunicorn --workers 2 --bind 127.0.0.1:8000 wsgi_app:app

El flag --workers 2 lanza dos procesos. El --bind conecta la IP de localhost al puerto 8000. Y al final, wsgi_app:app indica el módulo y el método que Gunicorn debe ejecutar. Al entrar a esa URL en el navegador, verás el mensaje Hello WSGI World.

¿Qué es ASGI y en qué se diferencia de WSGI?

Python evolucionó y hoy maneja asincronismo con async/await. Esto permite atender muchos requests sin esperar que cada uno termine antes de procesar el siguiente. ASGI (Asynchronous Server Gateway Interface) es el protocolo que habilita ese comportamiento.

Funciona como puente igual que WSGI, pero soporta concurrencia real. La librería estrella aquí es Uvicorn, que ejecuta tu aplicación en varios hilos y aprovecha asyncio.

¿Cuándo usar ASGI en lugar de WSGI? Cuando tu framework soporta async, necesitas WebSockets, o tu app hace muchas operaciones de lectura y escritura simultáneas.

¿Cuál elegir según tu aplicación?

La decisión depende del tipo de código que estés corriendo. Estos son los puntos que debes evaluar:

• Aplicación síncrona: usa WSGI con Gunicorn. Es el caso de Django en versiones sin soporte async.
• Aplicación asíncrona: usa ASGI con Uvicorn. Es el caso típico de FastAPI moderno.
• WebSockets: obligatoriamente Uvicorn. WSGI no los soporta.
• Operaciones intensivas de I/O: ASGI es más rápido porque lee y escribe en varios hilos.

Uno de los secretos del rendimiento de FastAPI es justamente que usa múltiples hilos para operaciones de lectura y escritura.

¿Qué frameworks van con cada protocolo?

Cada framework de Python tiene sus aliados naturales en cuanto a servidores. La elección no es libre del todo: depende de cómo está construido el código que vas a desplegar.

• Django: compatible con WSGI (usando uWSGI o Gunicorn) y también con ASGI en versiones recientes.
• FastAPI: requiere Uvicorn. No funciona con uWSGI porque necesita hilos y soporte async nativo.
• Flask: tradicionalmente WSGI con Gunicorn, aunque hay extensiones para ASGI.

En producción, además del servidor de aplicación, necesitas un servidor web por delante. Lo más común es NGINX, que se conecta a los procesos de Gunicorn o Uvicorn y devuelve el código de respuesta al cliente.

¿Qué hace NGINX en un deploy de Python? Actúa como reverse proxy: recibe las peticiones HTTP del cliente y las redirige a los workers de Gunicorn o Uvicorn que están corriendo tu app.

¿Cómo levantar una app asíncrona con FastAPI?

El flujo es prácticamente idéntico al de WSGI, solo cambia la librería. Instalas Uvicorn y FastAPI, defines una app asíncrona y la ejecutas indicando el módulo, la app, el host y el puerto.

bash uvicorn fastapi_app:app --host 127.0.0.1 --port 9000

El reto que cierra la clase es justamente ese: levantar una aplicación asíncrona con FastAPI corriendo en el puerto 9000, mientras dejas la app WSGI activa en el 8000. Así puedes comparar ambos mensajes en paralelo y ver cómo conviven los dos protocolos en tu máquina.

¿Ya tienes claro cuál vas a usar en tu próximo proyecto? Cuéntame en los comentarios qué framework prefieres y por qué.