El libro de Williams Vincent es bastante completo y simple de entender, comprendo que el publico objetivo son personas que conocen django pero no han tenido tanta practica utilizando el framework. El uso de docker dentro del libro es algo que ayuda bastante a entender como funciona Django con Docker.
Aun así, solo explicare los últimos 3 capítulos, porque creo que trae cosas que siempre son utilizas de recordar y saber.
Capítulo 16: Rendimiento
Este capítulo comienza con una discusión sobre el apartado de "Django Debug Toolbar". Se destaca la necesidad de actualizar el URLconf para asegurarse de que la barra de herramientas solo aparezca cuando DEBUG esté establecido en True. Hay una mención de cómo la barra de herramientas puede minimizarse y las ventajas de sus configuraciones por defecto. Por ejemplo, puede mostrar la versión actual de Django en uso, el tiempo que tardó en cargar la página y la solicitud específica que se llamó.
Un aspecto destacado de la "Debug Toolbar" es su capacidad para mostrar las consultas SQL que se ejecutan. Para sitios grandes y mal optimizados, se pueden ejecutar cientos o incluso miles de consultas en una sola página, lo que puede ser un problema de rendimiento significativo.
El capítulo luego aborda cómo mejorar el rendimiento al optimizar las consultas a la base de datos. Se introduce el concepto de que, en general, es mejor tener menos consultas más grandes que muchas consultas pequeñas. Se presentan dos técnicas comunes para optimizar las consultas: select_related() y prefetch_related()
- select_related(): Esta técnica se utiliza para relaciones de valor único a través de una relación uno a muchos hacia adelante o una relación uno a uno. Crea un JOIN SQL e incluye los campos del objeto relacionado en la declaración SELECT. Como resultado, todos los objetos relacionados se incluyen en una única consulta de base de datos más compleja. Esta única consulta suele ser más eficiente que múltiples consultas más pequeñas.
- prefetch_related(): Se utiliza para un conjunto o lista de objetos, como una relación de muchos a muchos o de muchos a uno. Bajo el capó, se realiza una búsqueda para cada relación y la "unión" ocurre en Python, no en SQL. Esto le permite prebuscar objetos de muchos a muchos y de muchos a uno, que no pueden hacerse con select_related, además de las relaciones de clave externa y uno a uno que son compatibles con select_related.
También habla de cómo filtrar los resultados de una base de datos en Django usando un QuerySet. Aunque la página de resultados de búsqueda actualmente muestra todos los resultados del modelo Book, el objetivo es filtrar estos resultados en función de la consulta de búsqueda del usuario. Se mencionan múltiples formas de personalizar un queryset, incluida la posibilidad de usar un administrador en el modelo, pero se opta por la simplicidad al agregar un filtro con una sola línea.
Se introduce el concepto de usar contains (que distingue entre mayúsculas y minúsculas) o icontains (que no distingue entre mayúsculas y minúsculas) como buenos puntos de partida para el filtrado. Por ejemplo, se muestra cómo implementar un filtro basado en títulos que "contienen" la palabra "principiantes".
El capítulo continúa discutiendo el poder de la función filter() en Django y cómo es posible encadenar varios filtros juntos. Se introduce el concepto de Q objects para búsquedas más complejas que pueden requerir el uso de operaciones "OR", no solo "AND". Por ejemplo, se muestra cómo configurar un filtro para buscar un resultado que coincida con un título de "principiantes" o "api".
Capítulo 17: Seguridad
Este capítulo continúa la discusión sobre seguridad y como Django ya ha tomado cartas en el asunto, mencionando como prevenirlas en aplicaciones Django:
- Inyección SQL: El capítulo advierte sobre el peligro de las vulnerabilidades de inyección SQL y recomienda el "SQL Injection Cheat Sheet" del proyecto Open Web Application Security Project (OWASP) para obtener información más detallada sobre cómo prevenir estas vulnerabilidades.
- XSS (Cross-site scripting): XSS es un ataque en el que un atacante puede inyectar pequeños bits de código (típicamente JavaScript) en páginas web que luego se muestran a otros usuarios. Se proporciona un ejemplo en el que, en lugar de escribir una reseña normal de un libro, un usuario podría ingresar un script JavaScript que, si se almacena en la base de datos, se mostrará a todos los futuros usuarios de la página. Django ofrece protecciones contra ataques XSS escapando automáticamente caracteres específicos que son potencialmente peligrosos en las plantillas. Sin embargo, se enfatiza la importancia de ser cautelosos, incluso con estas protecciones en su lugar.
- CSRF (Cross-Site Request Forgery): CSRF es un tipo de ataque que explota la confianza que un sitio tiene en el navegador del usuario. Cuando un usuario inicia sesión en un sitio web, el servidor devuelve un token de sesión para ese usuario, que se incluye en los encabezados HTTP de todas las futuras solicitudes y autentica al usuario. El capítulo parece introducir el concepto de qué sucede si un actor malintencionado obtiene acceso a este token de sesión, pero el extracto se corta antes de proporcionar más detalles.
El capítulo también hace referencia a la configuración ENVIRONMENT y cómo se puede usar para agregar lógica condicional en el archivo de configuración de Django. Por ejemplo, si la aplicación está en producción, se debe asegurar que SECURE_BROWSER_XSS_FILTER esté configurado como True.
Capítulo 19: Despliegue
El Capítulo se centra en el despliegue de aplicaciones Django utilizando Docker en diferentes plataformas de VPS, como Heroku.
El capítulo comienza discutiendo cómo, aunque Heroku ha sido una opción popular para el despliegue durante muchos años, Docker ha ganado mucha tracción en el desarrollo local y también está empezando a dominar los despliegues. Se menciona la flexibilidad que ofrece Docker, permitiendo cambiar fácilmente entre proveedores de hosting sin tener que reconfigurar todo específicamente para cada proveedor.
A pesar de que hay dos opciones para desplegar contenedores en Heroku (usar un registro de contenedores para desplegar imágenes preconstruidas o añadir un archivo heroku.yml), el capítulo elige la segunda opción, ya que permite comandos adicionales y se asemeja más al enfoque tradicional de Heroku de usar un Procfile para la configuración.
Se introduce el concepto del archivo heroku.yml, similar al archivo docker-compose.yml utilizado para construir contenedores Docker locales. Este archivo es esencial para configurar cómo se desplegará y funcionará la aplicación en Heroku.