Python no es un lenguaje nuevo. Sin embargo, en los últimos años, su popularidad ha crecido de la mano del data science. Cada vez más analistas de datos usan Python como lenguaje principal. ¿Y cuál es la razón de este crecimiento, especialmente teniendo en cuenta la existencia de otros lenguajes y entornos específicos como R, Matlab u Octave?
Como siempre, hay muchas razones; pero quizás la principal sea la flexibilidad de Python. Python tiene un enorme número de librerías para todo tipo de aplicaciones; puede que para cada aplicación no sea el mejor entorno, pero siempre hay una alternativa en Python. Esto es muy útil para aplicaciones multidisciplinares, como el análisis de datos. Hay librerías decentes para el análisis de datos (Pandas, que hemos visto antes en este blog, scikit-learn, que veremos en el futuro, etc.); puede que R sea una mejor opción para el análisis puro; pero no tiene, por ejemplo, librerías buenas para crear entornos gráficos para crear aplicaciones de escritorio.
Hoy vamos a ver una de las killer apps de Python: Django. Django es una plataforma para programar aplicaciones web con servidores escritos en Python. De hecho, mucha gente empieza a usar Python por Django.
Pero, ¿qué tiene que ver esto con el análisis de datos o el data science? En algún momento querremos obtener datos de los usuarios, o bien mostrarles resultados. Otro uso común es servir datos de forma remota. No podemos hacer esto con facilidad con otras plataformas.
Antes de entrar en Django, daremos un breve repaso al funcionamiento práctico de una aplicación cliente-servidor. En las aplicaciones web, el servidor tiene acceso a una gran cantidad de datos o recursos, mientras que el cliente tiene acceso al recurso principal: el usuario. Por tanto, el servidor controla qué se envía o qué se hace para los usuarios y se diseña en torno a los recursos compartidos (bases de datos, nubes de computación ...), mientras que el cliente controla la presentación y la interacción con el usuario. El flujo de datos entre el cliente y el servidor se hace a través del intercambio de mensajes siguiendo un cierto protocolo. Normalmente, el cliente enviará un mensaje llamado petición al servidor (por ejemplo, solicitando datos de una base de datos) y el servidor envía una respuesta con los resultados de la petición (enviándole los datos solicitados por el cliente). Desde el punto de vista de la programación, este intercambio se realiza a través de los sockets. Los sockets son objetos o funciones que envían mensajes a una dirección de red o escuchan un puerto en espera de mensajes remotos. Con los sockets, necesitamos crear nuestro propio protocolo. Sin embargo, hay un protocolo muy extendido que podemos usar para no tener que lidiar con esta tarea: HTTP. HTTP es el protocolo usado por los sitios web, en el que los servidores y los recursos son direccionados mediante una URL. Cuando abrimos una página web, usamos un cliente (el navegador), que envía una petición al servidor indicado por la URL. El servidor responde con el contenido de la página (o un mensaje de error). Las peticiones pueden ser de tipo GET (pedimos un documento identificado por la URL) o POST (enviamos datos al servidor, por ejemplo el texto de un email), entre otros. Como analistas de datos, ¿para qué necesitamos saber esto? Pues bien, sobre HTTP, podemos intercambiar algo más que páginas web (documentos HTML), por ejemplo, documentos XML o JSON. ¿Ahora sí suena interesante, verdad? A esto lo llamaremos una API REST.
¿Cómo podemos hacer todo esto en Python? La respuesta es Django. Django nos da una plataforma para la creación de apps de servidor. Una app es un conjunto de clases y funciones que llevan asociadas una serie de URLs que pueden ser llamadas desde un cliente a través de una petición. Cada función procesa la petición y puede devolver una respuesta.
Las apps de Django siguen una estructura Modelo-Vista-Controlador. Los modelos representan los datos que usa la aplicación (por ejemplo, usuarios, amistades o fotos en una red social); los controladores (vistas en la jerga de Django) son funciones que procesan las peticiones y devuelven una respuesta; y las vistas (plantillas) configuran las respuestas devueltas por las vistas. No, eso no es un error; en Django, se llama vistas a los controladores y plantillas a las vistas. Django usa una base de datos como soporte para el almacenamiento. Por defecto, usa SQLite, pero es compatible con muchas otras tecnologías.
El flujo de trabajo en Django suele comenzar con la creación de modelos de los datos que queremos enviar a los clientes. Los modelos son clases que representan los datos almacenados en la base de datos de soporte. Normalmente, empezaremos con una base de datos vacía y controlada exclusivamente por la aplicación. Hay maneras de usar bases de datos existentes; veremos esto en entradas futuras.
Una vez que se han creado los modelos, trabajaremos sobre las vistas, decidiendo qué queremos enviar a los clientes y cómo procesamos sus peticiones. La política de acceso (qué cliente puede ver qué datos) se suele decidir aquí (aunque por cuestiones de estilo, hay formas de hacerlo en los modelos). Las vistas son funciones que toman como entrada la petición del cliente, realizan una acción sobre la base de datos y, opcionalmente, devuelven una respuesta.
Generalmente, nos interesará que la respuesta tenga un formato específico (HTML, XML, JSON, etc). Hacer esto en la propia vista es posible, pero no recomendable. Por tanto, Django usa las plantillas, que son documentos formateados con huecos que se rellenan antes de ser devueltos por la vista.
Finalmente, configuramos el entorno Django que soporta las aplicaciones, configurando las URL y lanzando el servidor.
Hay muchas librerías que pueden usarse sobre Django, que proporcionan modelos, vistas y plantillas prefabricadas, entre otras cosas. De especial interés para nosotros será Django REST Framework, que nos dará los materiales para construir una API REST.
En entradas futuras, veremos cómo construir una app simple en Django, y la iremos complicando hasta que podamos servir datos de una base de datos en formato JSON usando una API REST.