Creando nuestro primer ejemplo completo de hola mundo en Django 6

▶

Cuando empezamos a trabajar con cualquier tecnología como Django, uno de los momentos más emocionantes es ver aparecer el clásico mensaje de “Hola Mundo” en el navegador. Es el punto exacto donde te das cuenta de que tu entorno funciona, ya que sabemos ¿Qué es Django y para qué sirve? vamos al siguiente punto que es hacer un Hola Mundo.

En esta entrada vamos a ver cómo crear nuestra primera aplicación en Django, entender qué diferencia hay con un proyecto y cómo conectar todo para ver resultados en el navegador.

Vamos a conocer cómo podemos trabajar con dos capas de nuestro MTV de manera básica, que viene siendo la capa de la Vista y el Template, además de esto de otra capa que viene siendo la que nos permite el ruteo que es una capa intermedia.

¿Qué es una aplicación en Django y en qué se diferencia de un proyecto?

Una de las primeras cosas que tenemos que entender cuando comenzamos en Django es la diferencia entre proyecto y aplicación; ya que, es el único framework cuya estructura es organizado mediante proyectos y aplicaciones.

En pocas palabras:

• Un proyecto es el contenedor global que define la configuración general de tu sitio.
• Una aplicación es una pieza funcional dentro de ese proyecto; puede encargarse de manejar usuarios, un blog, una API, etc.

Si lo comparamos con otros frameworks como Laravel o CodeIgniter: el proyecto sería el sitio completo y las aplicaciones serían los módulos que lo componen.

En Django puedes tener muchas apps dentro de un mismo proyecto, cada una independiente y reutilizable.

Un proyecto en Django consta de una o muchas aplicaciones que es lo que nosotros vamos a crear en este punto; vamos a crear al menos una aplicación para poder hacer algo interesante en nuestro proyecto recién creado.

Proyectos vs aplicaciones - ¿Cuál es la diferencia entre un proyecto y una aplicación?

Una aplicación es una aplicación web que hace algo, por ejemplo, un sistema de registro web, una base de datos de registros públicos, una Api Rest, una app de venta de algo, etc.

Un proyecto es una colección de configuraciones y aplicaciones para un sitio web en particular. Un proyecto puede contener múltiples aplicaciones. Una aplicación puede estar en múltiples proyectos.

El uso de Django para crear aplicaciones, está fuertemente ligado al concepto modularización, y por ende, podemos crear múltiples aplicaciones pequeñas que realizan tareas en particular, para que en conjunto, podemos tener la aplicación final que nosotros queremos; por ejemplo, para una aplicación tipo blog:

1. Una aplicación para el listado y detalle de los posts.
2. Una aplicación para manejar la autenticación, registro y derivados.
3. Una aplicación para manejar los contactos, así como manejar comentarios de post y demás.
4. Una aplicación para manejar una api rest.
5. Una aplicación para manejar información base, como de contacto y "acerca de".

️ Comandos Básicos de Python para Django

No creas que se me olvidó grabar este video sobre los comandos básicos. Aquí te muestro las funcionalidades esenciales del gestor de paquetes PIP:

1. Gestión de Paquetes

Instalar (pip install): Ya lo hicimos antes. Este comando se usa para instalar paquetes. Colocas el nombre del paquete que quieras instalar: django, Flask, Tkinter, etc.

$ pip install <paquete>

Desinstalar (pip uninstall): De manera similar, tenemos pip uninstall, que sirve para desinstalar el paquete. (No lo voy a ejecutar ahora para no desinstalar nada).

$ pip uninstall <paquete>

Ver Paquetes Instalados (pip freeze): Este comando ya lo hemos utilizado varias veces, así que no creo que haga falta utilizarlo otra vez.

$ pip freeze

2. Gestión de Requerimientos (requirements.txt)

Usualmente, tenemos un archivo llamado requirements.txt. Este archivo lista los requerimientos o los paquetes de nuestro proyecto (es decir, qué necesita para funcionar), incluyendo sus versiones específicas. De momento solo necesitamos Django.

Esto es importante porque cuando utilizas servicios de despliegue como Railway u otros, el servicio busca este archivo automáticamente, ahorrándote trabajo.

Generar el Archivo (pip freeze > requirements.txt): Este comando es para generar dicho archivo. En vez de arrojar la salida por la terminal, la flechita (>) redirige esa salida al archivo que, por convención, se llama requirements.txt.

$ pip freeze > requirements.txt

Instalar desde el Archivo (pip install -r requirements.txt): Este comando se emplea para instalar todos los paquetes listados en ese archivo.

$ pip install -r requirements.txt

Preparando el entorno de trabajo en Django

Antes de crear la aplicación, necesitamos tener Django instalado y un proyecto base.

Desde la terminal, ejecutamos:

$ django-admin startproject firstProject

Esto crea una estructura como esta:

firstProject/
   manage.py
   firstProject/
       __init__.py
       settings.py
       urls.py
       asgi.py
       wsgi.py

Cada archivo tiene su función bien clara. Por ejemplo:

• manage.py: Una utilidad de la línea de comandos que le permite interactuar con este proyecto Django de diferentes formas y puedes obtener más información en la documentación oficial.
• __init__.py: Un archivo vacío que le indica a Python que este directorio debería ser considerado como un paquete Python.
• settings.py: Ajustes/configuración para este proyecto Django; nos define un conjunto de configuraciones que podemos aplicar sobre el proyecto de manera global, entre los principales tenemos:
  • ALLOWED_HOSTS: Aquí colocaremos el dominio que utilizaremos cuando pasemos nuestra aplicación a producción.
  • INSTALLED_APPS: Indica las aplicaciones instaladas. Fíjate que ya tenemos varias cosas preinstaladas de Django (otra vez, el concepto de "baterías incluidas"):
    • django.contrib.admin: El hermoso Django Admin.
    • django.contrib.auth: Para la parte de autenticación (ya tenemos un modelo de usuarios básico listo).
    • django.contrib.contenttypes, sessions, messages, y staticfiles.
  • MIDDLEWARE: Son los intermediarios. Esto lo explicaremos más adelante, pero en resumidas cuentas, cuando el usuario hace una petición a nuestro servidor, el middleware puede ser una clase o función que se ejecuta en el medio para hacer algo (por ejemplo, verificar los accesos a un módulo de administración).
  • TEMPLATES: Este es el manejador de templates (el motor de plantillas de Django) que permite gestionar la parte de presentación.
  • DATABASES: Por defecto, empleamos SQLite como base de datos. (La base de datos se generará cuando ejecutemos las migraciones más adelante).
• urls.py: Las declaraciones URL para este proyecto Django; desde aquí podemos (por ejemplo) cargar más archivos de URLs de otras aplicaciones o dependencias.
  • Por buenas prácticas, en este archivo se colocan solo las URLs de las aplicaciones que vamos a utilizar (rutas globales), y no las rutas locales de esas aplicaciones. Las rutas locales las creamos directamente dentro de cada aplicación.
  • Puedes ver un ejemplo de esto, donde se incluye la aplicación admin:

    • urlpatterns = [
          path('admin/', admin.site.urls),
      ]

  • urlpatterns: Esta parte es importantísima. La lista urlpatterns debe tener ese nombre sí o sí, porque es la que va a leer internamente Django para cargar esas URLs.
• asgi.py: Archivo de entrada para trabajar con servidores ASGI y realizar el deploy.
• wsgi.py: Archivo de entrada para trabajar con servidores WSGI y realizar el deploy.

Ejecutar el proyecto en un servidor

Ya con un proyecto nuevo creado, lo siguiente que necesitamos es ir visualizando lo elaborado en el navegador; para eso, necesitamos levantar el servidor de desarrollo; como comentamos antes, mediante la línea de comandos, tenemos un comando para levantar el servidor de desarrollo:

$ python manage.py runserver

Y tenemos un resultado como el siguiente:

Nov 17, 2025 - 16:11:19
Django version 5.0.3, using settings 'mystore.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CTRL-BREAK.

Por defecto, Django emplea un servidor de tipo WSGI de las siglas Interfaz de Pasarela del Servidor Web, o Web Server Gateway Interface en inglés (WSGI), es una interfaz estándar entre el servidor web y aplicaciones web escritas en Python que en pocas palabras, permite la comunicación con nuestra aplicación en Django.

Finalmente, si vamos a la URL señalada anteriormente, veremos:

Obviamente, todavía no hemos implementado nada, pero, es por lo menos curioso, además de necesario saber si el proyecto esta funcional para poder seguir avanzando en la creación de nuestra primera aplicación.

Creando nuestra primera aplicación con startapp

▶

Dentro del proyecto, creamos la aplicación:

$ python manage.py startapp firstApp

Esto genera una estructura nueva:

firstApp/
   __init__.py
   admin.py
   apps.py
   migrations/
   models.py
   tests.py
   views.py

Una aplicación en Django no es más que un paquete de Python con un esquema estándar.

Dentro de esta carpeta iremos colocando la lógica de negocio, las vistas y las plantillas.

• python manage.py: La línea de comandos de nuestro proyecto.
• startapp: El comando para iniciar una aplicación.
• firstApp: El nombre que le doy a la aplicación. (La llamo comments porque será para hacer un sencillo CRUD; para mí, los CRUD son la herramienta fundamental para entender de manera básica cualquier tecnología).

Registrando la aplicación en el proyecto

▶

Como hablamos anteriormente, básicamente el proyecto viene siendo el elemento global y que permite contener una o muchas aplicaciones, como la llamada firstProyect que creamos anteriormente; entonces, para poder emplear la aplicación a lo largo de nuestro proyecto, tenemos que registrar la aplicación dentro de nuestro proyecto; para esto, tenemos que abrir el archivo llamado settings.py y ubicar la opción llamada INSTALLED_APPS:

Abrimos el archivo settings.py del proyecto y buscamos la lista INSTALLED_APPS.

Ahí añadimos nuestra aplicación:

INSTALLED_APPS = [
   'django.contrib.admin',
   'django.contrib.auth',
   'django.contrib.contenttypes',
   'django.contrib.sessions',
   'django.contrib.messages',
   'django.contrib.staticfiles',
   'firstApp',  # nuestra app
]

Una vez registrada, ya podemos usarla dentro del proyecto.

Opcional: Gemini CLI y/o Gemini Agent, tu asistente IA

Antes de empezar a desarrollar, quiero hacerte una recomendación rápida para que tengas un "amigo" que te asista.

Te sugiero instalar o configurar algún asistente de Inteligencia Artificial (IA). En este caso, te recomiendo Gemini, que es completamente gratuito, aunque también puedes emplear Claude o el que tú prefieras.

1. Gemini Code Assistant (VS Code Extension)

Vamos a repasar rápidamente dos herramientas. La información detallada (el paso a paso) la dejaré en un video en mi canal de YouTube y en mi blog.

En primer lugar, te recomiendo que busques en la parte de Extensiones de VS Code:

Busca "Gemini".

Verás el asistente que puedes instalar. Siempre debes estar pendiente de que diga "por Google" y que tenga el verificado (suele ser el primero):

https://marketplace.visualstudio.com/items?itemName=Google.geminicodeassist

Luego, te aparecerá una ventana para que te autentiques (con un botón grande de Login).

Una vez autenticado, podrás preguntar cualquier cosa asociada a este proyecto directamente en VS Code.

Estructura de la aplicación

Si entramos dentro de la carpeta que creamos anteriormente cuyo nombre es de firstProyect (que es nuestra aplicación en Django y que no es más que un módulo en Python):

1. __init__.py: Archivo especial de Python que indica que esta carpeta es un módulo.
2. admin.py: Archivo de Django en la cual podemos registrar modelos para emplearlos en una aplicación que nos ofrece Django para realizar la gestión de datos.
3. apps.py: Archivo de configuración de la aplicación.
4. migrations/: Carpeta desde la cual podemos gestionar las migraciones.
5. models.py: Archivo desde el cual podemos crear los modelos de la aplicación y esta es una de las capas de nuestro MTV.
6. tests.py: Archivo para realizar pruebas de la aplicación.
7. views.py: Archivo para crear las funciones o vistas para hacer la lógica y es la capa de la lógica de negocio que se encarga de conectar la capa del modelo con la del template; esta viene siendo la capa de la vista o -parte- el controlador en nuestro MVC.

Por supuesto, estos son los archivos y carpetas iniciales que podemos extender para agregar más configuraciones como formularios, urls, etc.

Creando nuestra primera función en la vista “Hola Mundo” en Django

▶

Para hacer esto, recuerda que previamente tienes que tener instalado y creado tu proyecto en Django y también creada tu aplicación, cosa que ya hicimos anteriormente.

Vamos a ir a:

firstProject -> firstApp

Que viene siendo dentro de tu proyecto y luego dentro de la aplicación que creamos en la entrada anterior:

firstProject/firstApp/views.py

Aquí tenemos todo lo necesario para arrancar la aplicación web de tipo Hola Mundo con Python.

Dentro del archivo views.py de nuestra aplicación escribimos lo siguiente:

from django.http import HttpResponse
def index(request):
   return HttpResponse("Hola Mundo")

Con el código anterior, podemos ver lo simple y elegante que es Django: una función, una respuesta HTTP, y listo.

La clase HttpResponse se encarga de devolver un contenido que el navegador puede interpretar.

Una aplicación en Django es simplemente un paquete de Python que sigue un determinado esquema de archivos y estructura base que podemos emplear para nuestros proyectos web en Django.

Configurando las rutas (URLs) para nuestra vista

Ahora, ya tenemos una función de ejemplo que está lista par ser consumida mediante nuestro navegador, específicamente mediante una URL o ruta; así que ahora tenemos que explicar una nueva capa que será la que nos permitirá crear este ruteo.

Vamos a crear la ruta para que pueda ser consumida mediante nuestro navegador específicamente mediante una ruta o URL; para eso vamos a crear un archivo llamado urls.py al archivo de urls.py DENTRO de nuestra aplicación:

firstApp/urls.py

from django.urls import path
from . import views
urlpatterns = [
    path('', views.index, name='index'),
]

Si has trabajado en otros frameworks modernos como Laravel o CodeIgniter 4, esto te resultará muy común; primero estamos importando una de nuestras capas representada por el views.py y luego o estamos creando un array de rutas, que de momento tenemos solamente una ruta por lo tanto es un array de una posición; en la cual estamos indicando el path, luego la función que se encarga de resolver el path y le estamos dando un nombre que es completamente opcional y en otra entrada veremos para qué nos sirve definir un nombre a una ruta.

Después, registramos ese archivo en las rutas principales del proyecto (firstProject/urls.py):

from django.contrib import admin
from django.urls import path, include
urlpatterns = [
   path('admin/', admin.site.urls),
   path('firstApp/', include('firstApp.urls')),
]

Ver nuestro Hola Mundo en el navegador

Para poder finalmente todo nuestro trabajo tenemos que ejecutar el siguiente comando a la altura de tu proyecto (donde se encuentra un archivo llamado manage.py): 

$ python manage.py runserver

Y con esto, si vamos a:

http://127.0.0.1:8000/fisrtApp/

Django levantará su servidor de desarrollo y te mostrará una dirección local, normalmente http://127.0.0.1:8000/.

Si visitas http://127.0.0.1:8000/firstApp/, verás algo como esto:

Ejecutar el proyecto en un servidor

▶

Recordemos el comando runserver para ejecutar el servidor:

$ python manage.py runserver

Al ejecutarlo, la terminal muestra información útil para el desarrollo: la versión de Django, la fecha y hora actual, y la ruta de acceso.

Servidores Síncronos (WSGI)

Es importante notar que el servidor de desarrollo de Django (y la mayoría de las implementaciones por defecto) es de tipo WSGI (Web Server Gateway Interface).

• WSGI define una interfaz estándar para servidores web de Python de tipo síncrono.
• Programación Síncrona: Esto significa que las operaciones tienen que ser lineales. No puedes utilizar comandos de programación asíncrona (como await) directamente en una función de vista síncrona, ya que el servidor no lo soporta de forma nativa.

Servidores Asíncronos (ASGI)

La programación asíncrona requiere un servidor de tipo ASGI (Asynchronous Server Gateway Interface).

En Python, tenemos dos tipos principales de servidores que se usan comúnmente en producción:

Servidor    Tipo de Servidor    Propósito
Gunicorn    Síncrono (WSGI)    Se utiliza para proyectos tradicionales de Django o Flask.
Uvicorn    Asíncrono (ASGI)    Se utiliza para programación asíncrona, aunque también puede servir código síncrono.

Esto es un tema más avanzado que se suele abordar al pasar a producción. Si bien la mayoría de las aplicaciones pueden funcionar perfectamente con un servidor síncrono.

Vistas, templates y rutas

▶

Ya no queremos retornar un HttpResponse simple; queremos que Django utilice un archivo HTML. Para esto, usamos el método de ayuda (shortcut) llamado render.

En el archivo de:

comment/views.py

Vamos a crear una función llamada add(), para agregar comentarios; de momento, el apartado para dibujar una vista:

def add(request):
    return render(request,'add.html')

Explicación del código anterior

La función anterior, llamada render() que es un shortcuts, recibe como parámetro principal, el template, que recuerda que es la página HTML, página que no existe y por lo tanto, tenemos que crearla.

• Los shortcuts, no son más que una recopilación de funciones de ayuda y clases que existen para distintos propósitos de la aplicación.

Templates

Los templates o plantillas son el mecanismo que desde Django puede generar HTML dinámicamente en base a una alguna sintaxis especial que describe cómo se insertará el contenido dinámico.

Cada aplicación puede tener su carpeta de templates para definir las páginas de dichas aplicaciones; esta carpeta por defecto no viene creada en las aplicaciones, ya que es opcional; la razón de esto se debe a qué desde las vistas, necesariamente no tenemos que devolver un template; podemos retornar otros formatos como JSONs, XMLs, un simple texto, etc.

Caso práctico

Los templates están almacenados en una carpeta a nivel de la aplicación llamada “templates”, templates que definen las páginas HTML con el contenido que queremos presentar; como en la vista empleamos:

return render(request,'add.html')

Tenemos que crea una página:

comments/templates/add.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
  <body>
    <h1>Page to add</h1>
  </body>
</html>

Ahora, para poder visualizar algo en el navegador, necesitamos un mecanismo con el cual podamos enlazar la vista anterior con alguna URI que podamos consumir mediante el navegador; necesitamos crear la ruta.

Pase de parámetros al template

▶

La idea central de un framework como Django es que el contenido no sea estático, sino que provenga de una fuente de datos (generalmente la base de datos).

return render(request,'comments/add.html',{'data':'Contenido'})

Desde la función de la vista, podemos pasar datos al template utilizando un diccionario de Python como tercer argumento de la función render().

Diccionario de Contexto: Un diccionario en Python se compone de pares clave-valor.

• La clave ('data') será el nombre de la variable que usaremos en el template.
• El valor ('Contenido') es el dato real que queremos mostrar.

Desde el template:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8">
        <meta http-equiv="X-UA-Compatible" content="IE=edge">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <title>Document</title>
    </head>
    <body>
       {{ data }}
    </body>
</html>

Carpetas contenedoras para los templates

▶

Como hablamos antes, en los views.py de las aplicaciones, podemos tener múltiples  funciones de vistas, por lo tanto, siempre es buena idea modularizar nuestra aplicación con carpetas; podremos crear una carpeta contenedora para el template de add.html.

Y desde el render():

def add(request):
    return render(request,'comments/add.html')

Por supuesto, puedes colocar una jerarquía de carpetas mayor si lo consideras necesario.

Implementación del Cambio

• Crear Subcarpeta: Dentro de comments/templates/, creamos una subcarpeta con el mismo nombre de la aplicación: comments/.
• Mover el Template: Movemos el archivo add.html a la nueva ubicación: comments/templates/comments/add.html.
• Actualizar la Vista: Obviamente, si ahora visitamos la página, la aplicación fallará con el error: "TemplateDoesNotExist" (el template no existe).
• Corregir en views.py: Tenemos que actualizar la referencia en la función render de nuestra vista como mostramos antes.

¿Por Qué Usar Subcarpetas?

Aunque al principio no parezca crucial, la organización con subcarpetas es una buena práctica vital para evitar conflictos y mantener la claridad en aplicaciones grandes.

• Evitar Conflictos de Nombres: Si tienes una aplicación que hace varias cosas (por ejemplo, una aplicación de blog), podrías necesitar un archivo llamado list.html para el listado de Posts y otro list.html para el listado de Categorías. Si los dejas en la raíz de templates/, Django no sabrá cuál usar.
• Referencia Única: Al colocar el template dentro de una subcarpeta (nombrada idealmente como la aplicación, ej. comments/), le das una ruta más única y evitas que Django se confunda si en otra aplicación existe un template con el mismo nombre.

Conclusión

En este primer ejercicio aprendimos el flujo completo para levantar una aplicación Django:

1. Crear un proyecto base (startproject)
2. Crear una aplicación dentro del proyecto (startapp)
3. Registrar la aplicación en settings.py
4. Crear una vista (views.py)
5. Configurar las rutas (urls.py)
6. Ejecutar el servidor y probar en el navegador

Con esto ya tenemos una app completamente funcional que responde a una petición HTTP.
A partir de aquí el camino sigue con modelos, templates y formularios, pero lo importante es que ya comprendiste cómo se conectan las piezas básicas de Django.

Preguntas frecuentes

¿Cuál es la diferencia entre un proyecto y una aplicación en Django?
Un proyecto es el contenedor general; una aplicación es una parte funcional dentro de él.

¿Dónde se registran las aplicaciones?
En el archivo settings.py, dentro de la lista INSTALLED_APPS.

¿Por qué no se muestra mi “Hola Mundo”?
Asegúrate de haber creado y enlazado correctamente el archivo urls.py tanto en la aplicación como en el proyecto.

¿Puedo tener varias aplicaciones en un mismo proyecto?
Sí, y es una de las grandes ventajas de Django: puedes modular tu proyecto en tantas apps como necesites.

El siguiente paso, es conocer como emplear los modelos en Django.