Servidor web — Python: Desarrollo web con Flask

• Procesos en la computadora
• ¿Cómo se comunican dos computadoras?
  • ¿Con qué se conectan?
• ¿Qué es un servidor web?
• ¿Cómo se conectan el servidor web y tu sitio en Python?
  • CGI: el primer intento
• WSGI: una mejor forma para Python
• Servidores y herramientas comunes

En esta lección vamos a entender por qué necesitamos un servidor web y cómo se da la comunicación entre dos computadoras a través de la red.

Vamos a ir paso a paso, como si estuviéramos conversando con un amigo que ya tiene algo de experiencia con Python, pero apenas está explorando cómo funcionan los servidores y la red.

Procesos en la computadora

Antes de hablar de redes, hay que entender un concepto muy importante en cualquier sistema operativo: los procesos.

⏬ Por ejemplo:

• Tu navegador web tiene un proceso por cada pestaña.
• Si abres dos editores de texto, cada uno tiene su propio proceso.

Esto significa que si una pestaña del navegador se cuelga, las otras pueden seguir funcionando bien, porque cada una es independiente.

Un proceso puede tener varios hilos (threads), que son subprocesos que permiten realizar múltiples tareas al mismo tiempo dentro del mismo proceso.

Si estás en Linux, puedes ver los procesos en ejecución con los comandos:

ps aux
top

¿Cómo se comunican dos computadoras?

Cuando dos computadoras se comunican por la red, realmente no se están conectando “entre sí” como un todo, sino que lo que hacen es conectar un proceso en una computadora con otro proceso en otra. O sea, la comunicación es entre programas.

⏬ Por ejemplo:

• Un navegador (cliente) quiere mostrar una página web.
• Ese navegador se conecta a otro programa (servidor web) en otra máquina, que tiene la información del sitio.

El navegador sería en este caso el cliente, porque es quien inicia la conexión.

¿Con qué se conectan?

Para que esta conexión se realice, se utilizan dos datos clave:

Cuando un programa quiere permitir conexiones, “abre un puerto” en una interfaz de red. El sistema operativo se encarga de que los mensajes que lleguen a ese puerto se envíen al proceso que lo está escuchando.

⏬ Por ejemplo:

• Un servidor web normal que usa HTTP escucha en el puerto 80
• Uno que usa HTTPS escucha en el puerto 443

Esto lo sabe tu navegador, por eso cuando escribes http:// o https://, él automáticamente sabe qué puerto usar. Pero en desarrollo local es normal usar otros puertos, como el 3000 o el 4000:

http://localhost:3000

¿Qué es un servidor web?

• Recibe un mensaje del navegador
• Lo pasa al código del sitio (por ejemplo, una aplicación en Python)
• Recoge la respuesta (HTML, JSON, etc.)
• Se la devuelve al navegador

Además, puede hacer otras cosas útiles como:

• Guardar resultados en caché
• Reescribir URLs
• Servir archivos estáticos (imágenes, CSS, JS)
• Balancear carga entre varios servidores (cuando hay mucho tráfico)
• Hacer de proxy inverso

Y lo mejor de todo: el servidor web no necesita saber en qué lenguaje está hecho el sitio. Existe un estándar para que puedan comunicarse.

¿Cómo se conectan el servidor web y tu sitio en Python?

CGI: el primer intento

El primer estándar fue CGI(Common Gateway Interface). La idea era simple:

• Cuando llega una solicitud, el servidor ejecuta un script (un archivo ejecutable)
• Le pasa variables del entorno con los datos del request
• El script devuelve un texto con la respuesta HTTP por la salida estándar (stdout)

Resumen del flujo:

1. El navegador pide una página
   
2. El servidor prepara las variables del entorno
   
3. Ejecuta tu script y le pasa los datos
   
4. Tu script procesa el pedido y genera una respuesta (HTML u otro formato)
   
5. El servidor recoge la salida del script
   
6. Se la devuelve al navegador
   

El problema principal con CGI es que cada vez que llega una solicitud, se vuelve a ejecutar el script desde cero. Esto puede volver todo muy lento.

WSGI: una mejor forma para Python

Para resolver los problemas de CGI, la comunidad Python diseñó un estándar más eficiente: WSGI (Web Server Gateway Interface).

Puedes leer el estándar completo en su PEP oficial: PEP 3333

En lugar de ejecutar un script cada vez, con WSGI se define una función en Python que el servidor web va a invocar directamente cada vez que llegue una solicitud.

Esa función recibe dos cosas:

• Un diccionario environ con la información del request
• Una función start_response() que usas para definir el estado y los headers

Aquí tienes un ejemplo básico de una aplicación WSGI:

def app(environ, start_response):
    data = b"Hola Mundo!\n"
    start_response("200 OK", [
        ("Content-Type", "text/plain"),
        ("Content-Length", str(len(data)))
    ])
    return iter([data])

¿Qué hace esto?

• Define el estado 200 (OK)
• Indica que el contenido es texto plano
• Devuelve la frase “Hola Mundo!” como respuesta

💡 En este caso, app es un callable (algo que se puede llamar como una función). Todos los frameworks modernos lo implementan así.

Por ejemplo:

Servidores y herramientas comunes

Veamos un resumen de las herramientas más usadas tanto para desarrollo como para producción:

Por lo general, no se usa gunicorn de forma directa en internet. Se suele poner detrás de nginx o Caddy, que se encargan del tráfico externo, los certificados HTTPS, etc.

Un esquema común es:

Usuario -> nginx -> gunicorn -> Tu app Django/Flask

Trabajo independiente

1. Guarda el código de la aplicación WSGI en un módulo llamado example.py.
2. Instala gunicorn. Siempre instala todo en un entorno virtual.
3. Puedes crearlo con cualquier herramienta.
4. Inicia el módulo con el comando gunicorn -w 4 example:app: con este comando iniciamos el servidor WSGI gunicorn y le indicamos la ruta a nuestra función de aplicación.
5. Va al navegador a la dirección que aparece en la salida y observa el resultado.

Materiales adicionales

1. Sockets de red 📚 Wikipedia
2. WSGI 📚 Wikipedia