Mi proyecto en Python del Curso de Adecco para desempleados de larga duración.

El proyecto Cartelera de Cine en Python es una aplicación web full stack profesional, desarrollada como un sistema modular y escalable diseñado para la gestión integral de la operación diaria de un cine. Está orientado tanto al uso comercial real como a demostrar mis competencias como desarrollador full stack especializado en ecosistemas Python, FastAPI, SQLAlchemy, Jinja2 y bases de datos SQLite/SQL sobre entornos GNU/Linux.

La solución representa un producto de Software Libre vendible a cualquier empresa del sector ocio y cinematográfico, especialmente cines independientes, asociaciones culturales, salas alternativas o cadenas locales que necesitan una plataforma moderna, segura y eficiente.

1. Objetivo del Proyecto

El objetivo es doble:

1.1. Objetivo Técnico (para empresas de desarrollo / empleo)

Demostrar experiencia sólida en:

• Desarrollo full stack con Python.
• Construcción de APIs REST con FastAPI.
• Diseño de bases de datos relacionales (ORM SQLAlchemy).
• Programación orientada a objetos.
• Construcción de interfaces web con Bootstrap, HTML5, CSS y JS.
• Arquitectura modular mantenible y orientada a negocio real.
• Trabajo con estándares profesionales (entidades, controladores, servicios, rutas, seguridad).

1.2. Objetivo Comercial (para vender el software a un cliente real)

Crear un sistema listo para:

• Implementarse en un cine real de Asturias.
• Adaptarse a cualquier negocio relacionado (teatros, auditorios, centros culturales).
• Gestionar películas, horarios, salas, usuarios, ventas y socios.
• Integrarse con un futuro sistema de venta de entradas, TPV o pasarelas de pago.
• Servir como producto llave en mano para empresas pequeñas sin software propio.

2. Descripción General del Sistema

La plataforma permite gestionar completamente:

• Cartelera y catálogo de películas.
• Horarios y sesiones.
• Salas y capacidades.
• Ventas de entradas y recaudación.
• Usuarios, roles y autenticación.
• Programa de socios y fidelización.

Todo ello sobre una arquitectura limpia, robusta y escalable, adecuada tanto para entorno académico como industrial.

3. Enfoque Técnico – Lo que un técnico de RRHH verá en tu CV

El proyecto demuestra competencia real en:

Backend

• Python 3
• FastAPI para API REST de alto rendimiento
• SQLAlchemy ORM
• Pydantic para validación de datos
• Arquitectura en capas:
  • models/ (entidades)
  • routes/ (endpoints)
  • services/ (lógica de negocio)
  • database/ (motor y esquema)
  • schemas/ (Capa de Serialización/Validación)

Frontend

• Plantillas Jinja2
• Bootstrap 4/5
• HTML5 + CSS3 + JavaScript

DevOps y despliegue

• Proyecto preparado para producción (Uvicorn/Gunicorn)
• Entornos virtuales y requirements.txt
• Arquitectura documentada para despliegue en Linux (Debian)

Buenas prácticas

• Código modular y mantenible
• Entidades bien definidas
• Relaciones ORM correctas
• Servicios independientes y desacoplados
• Documentación profesional (README.html completo)

4. Enfoque Comercial – Lo que verá un cliente que quiera comprar el software

El sistema le aporta:

4.1. Control total del negocio

• Gestión de salas, precios, horarios y sesiones.
• Gestión de catálogo de películas.
• Análisis de ventas y recaudación.
• Control de aforo por sala y sesión.
• Gestión de clientes y socios.

4.2. Ahorro de costes

• Solución completa sin depender de software privativo.
• Código abierto y adaptable.
• Mantenimiento sencillo.
• Disponible para instalar en servidores locales o cloud.

4.3. Facilidad de uso

• Interfaz clara.
• Gestión centralizada.
• API REST que permite generar apps móviles o paneles adicionales.

5. ¿Qué aporta este proyecto a una empresa de Asturias?

Ideal para empresas tecnológicas, consultoras, pymes o startups del Principado que busquen un perfil técnico completo. Demuestras:

• Capacidad para crear un producto real end-to-end.
• Madurez arquitectónica.
• Documentación profesional.
• Conocimiento profundo de Python y del software libre.
• Orientación a resultados y mentalidad de producto.
• Competencias para integrarte en un departamento de desarrollo full stack.

Herramientas que dominas gracias a este proyecto:

• Python moderno
• FastAPI (framework ampliamente usado en España)
• SQL (competencia clave en analistas y full stack)
• Bootstrap (estándar corporativo)
• Arquitectura limpia (Clean-like)

6. Propuesta de texto tipo presentación comercial (para un cliente)

Software de Gestión para Cines – Cartelera y Ventas
Plataforma profesional para la gestión integral de un cine: catálogo de películas, horarios, salas, ventas de entradas, clientes y socios. Desarrollado en Python y optimizado para negocios pequeños y medianos del sector ocio. Puede instalarse en servidor local o en la nube, con panel de administración, API propia y arquitectura escalable. Solución moderna, eficiente y adaptable a cualquier cine de Asturias.

7. Documentación Técnica

Bienvenido al repositorio oficial de Cartelera de Cine, una aplicación desarrollada en Python cuyo objetivo es gestionar de forma eficiente la cartelera digital de un cine. Este proyecto forma parte del aprendizaje del curso Python combinando conceptos de programación estructurada, POO, bases de datos, APIs y arquitectura web moderna.

🎯 Finalidad del Proyecto

El propósito de este proyecto es diseñar un sistema backend capaz de:

• 📌 Mostrar información de películas disponibles en cartelera.
• 🕒 Gestionar horarios y salas.
• 🎫 Administrar ventas de entradas y precios.
• 🎭 Organizar géneros y clasificaciones.
• 👥 Gestionar usuarios, autenticación y socios.
• 📚 Aplicar POO, estructuras de datos y buenas prácticas de desarrollo.
• 🚀 Integrar tecnologías modernas como FastAPI y SQLAlchemy.

👥 Equipo de Desarrollo

El proyecto ha sido diseñado y desarrollado por el siguiente equipo:

• Javier Cachón Garrido
• Kary Haro Pérez
• Manuel Jesús Marín García
• Reyes Delestal Barrios
• Iñaki Huete Montes

🛠️ Tecnologías utilizadas

Python 3 SQLAlchemy (ORM) SQLite Programación Orientada a Objetos FastAPI Jinja2 Bootstrap 4/5 HTML5 CSS3 JavaScript SQL Visual Studio Code

🏛️ Arquitectura del Sistema

El proyecto está basado en una arquitectura modular que separa claramente las entidades de dominio, la lógica de negocio y los servicios (endpoints, vistas, etc.).

A continuación se detallan todas las entidades con sus campos, sus responsabilidades dentro del sistema y las relaciones entre ellas, así como cómo se pueden modelar en la base de datos y, cuando procede, en el ORM.

📁 Estructura del Proyecto

A continuación se detalla la estructura recomendada del proyecto Cartelera de Cine en Python:

├── app/
│   ├── main.py
│   ├── models/              # Capa de Persistencia: Definiciones de Tablas (SQLAlchemy ORM)
│   │   ├── pelicula.py      # Entidad Pelicula
│   │   ├── genero.py        # Entidad Genero
│   │   ├── sala.py          # Entidad Sala
│   │   ├── horario.py       # Entidad Horario
│   │   ├── venta.py         # Entidad Venta
│   │   ├── socio.py         # Entidad Socio
│   │   └── login.py         # Entidad Login / Usuario
│   ├── schemas/             # Capa de Serialización/Validación (Pydantic, Marshmallow, etc.)
│   │   ├── pelicula.py      # Esquemas de entrada y salida para Peliculas
│   │   ├── genero.py        # Esquemas de entrada y salida para Generos
│   │   ├── sala.py          # Esquemas de entrada y salida para Salas
│   │   ├── horario.py       # Esquemas de entrada y salida para Horarios
│   │   ├── venta.py         # Esquemas de entrada y salida para Ventas
│   │   ├── socio.py         # Esquemas de entrada y salida para Socios
│   │   └── auth.py          # Esquemas para Login/Registro/Tokens
│   ├── services/            # Capa de Lógica de Negocio (El 'cerebro' de la aplicación)
│   │   ├── pelicula.py      # Funciones CRUD y validaciones de negocio para Pelicula
│   │   ├── genero.py        # Funciones CRUD y validaciones de negocio para Genero
│   │   ├── sala.py          # Funciones CRUD y validaciones de negocio para Sala
│   │   ├── horario.py       # Funciones CRUD y validaciones de negocio para Horario
│   │   ├── venta.py         # Funciones CRUD y validaciones de negocio para Venta
│   │   ├── socio.py         # Funciones CRUD y validaciones de negocio para Socio
│   │   └── auth.py          # Lógica para manejo de usuarios, *hashing* de contraseñas y tokens
│   ├── routes/              # Capa de Controladores: Manejo de Peticiones HTTP
│   │   ├── peliculas.py     # Rutas CRUD Peliculas (Llama a `services/pelicula.py`)
│   │   ├── generos.py       # Rutas CRUD Generos
│   │   ├── salas.py         # Rutas CRUD Salas
│   │   ├── horarios.py      # Rutas CRUD Horarios
│   │   ├── ventas.py        # Rutas CRUD Ventas
│   │   ├── socios.py        # Rutas CRUD Socios
│   │   └── login.py         # Rutas de autenticación / login (Llama a `services/auth.py`)
│   ├── database/
│   │   ├── db.py            # Motor de conexión SQLAlchemy y sesión (dependencia inyectada)
│   │   ├── db.sql           # Schema y seed de la base de datos (Script SQL)
│   │   └── db.db	     # Base de datos SQLite
│   ├── templates/           # Vistas (Jinja2, etc.)
│   │   ├── base.html        # Layout común
│   │   ├── peliculas/       # Vistas HTML de peliculas
│   │   ├── generos/         # Vistas HTML de generos
│   │   ├── salas/           # Vistas HTML de salas
│   │   ├── horarios/        # Vistas HTML de horarios
│   │   ├── ventas/          # Vistas HTML de ventas
│   │   ├── socios/          # Vistas HTML de socios
│   │   └── login/           # Vistas HTML de login/autenticación
│   └── static/ 
│       ├── Bootstrap/       # Hojas de estilo y JS de Bootstrap
│       │   ├── css/         # Archivos CSS de Bootstrap (bootstrap.min.css)
│       │   └── js/          # Archivos JavaScript de Bootstrap (bootstrap.bundle.min.js)           
│       ├── css/             # Hojas de estilo (CSS3/Bootstrap)
│       ├── js/              # Archivos JavaScript
│       └── img/             # Imágenes y assets
├── requirements.txt         # Dependencias del proyecto (Framework, ORM, Pydantic, etc.)
├── README.html              # Documentación inicial y guía de instalación
└── run.py                   # Script de inicio del servidor

🎬 Entidades del Sistema

🎞️ Pelicula

Responsable: JAVIER CACHÓN

Representa una película disponible (o no) en la cartelera.

Campos

• id: int — PK (clave primaria)
• titulo: string
• genero_id: int — FK → generos.id
• duracion: int
• director: string
• descripcion: string
• trailer: string (URL)
• productora: string
• idioma: string
• VOSE: boolean
• actores: lista (strings)
• disponible: boolean

Relaciones (modelo y ORM)

• Pelicula ↔ Género
  A nivel de base de datos:
  • La FK está en peliculas.genero_id apuntando a generos.id.
  A nivel lógico/ORM:
  • Cada Pelicula está asociada a un único Genero (lado N:1).
  • Cada Genero puede exponer una colección de peliculas (lado 1:N).
  Navegación típica en ORM:
  • Desde una película: pelicula.genero
  • Desde un género (si se implementa la colección): genero.peliculas
• Pelicula ↔ Horario
  A nivel de base de datos (modelo relacional):
  • La FK está en horarios.pelicula_id apuntando a peliculas.id.
  • Conceptualmente: una Pelicula puede tener muchos Horarios (1:N).
  Navegación ORM implementada:
  • Se navega desde Horario hacia Pelicula mediante horario.pelicula.
  • No se implementa en el ORM la colección pelicula.horarios (no hay atributo en la entidad Pelicula).
  Es decir, la relación es 1:N en la base de datos, pero la navegación en código se ha definido solo en el sentido Horario → Pelicula.

Servicios — Películas 🎬

• Añadir película
• Ver películas disponibles
• Ver detalle de una película
• Editar película
• Eliminar o desactivar película

Extra (futuro)

• Filtrar por género, duración, clasificación, etc.
• Búsquedas avanzadas (título, director, actor, etc.)
• Exportar catálogo a CSV/JSON

🏟️ Sala

Responsable: REYES

Representa una sala física del cine.

Campos

• id: int — PK
• numero: int
• capacidad: int (número de butacas)
• tipo: enum (normal, 3D, IMAX, premium)
• precio_base: float

Relaciones (modelo y ORM)

• Sala ↔ Horario
  A nivel de base de datos:
  • La FK está en horarios.sala_id apuntando a salas.id.
  A nivel lógico/ORM:
  • Una Sala puede tener muchos Horarios (1:N).
  • Un Horario se proyecta en una sola Sala (N:1).
  Dependiendo de la configuración del ORM se puede navegar:
  • Desde el horario: horario.sala
  • Desde la sala (si se define colección): sala.horarios

Servicios — Salas 🏟️

• Añadir sala
• Listar salas
• Editar sala (capacidad, tipo, precio_base)
• Activar/desactivar sala (si se implementa este campo)

Extra (futuro)

• Gestión de mantenimiento (salas fuera de servicio)
• Suplementos por tipo de sala (3D, IMAX, etc.)

🕒 Horario

Responsable: MANUEL

Representa una sesión concreta de una película en una sala y hora determinada.

Campos

• id: int — PK
• pelicula_id: int — FK → peliculas.id
• sala_id: int — FK → salas.id
• hora: datetime/string
• disponible: boolean

Relaciones (modelo y ORM)

• Horario ↔ Pelicula
  Modelo relacional:
  • Cada Horario referencia una única Pelicula mediante pelicula_id.
  • Una Pelicula puede tener muchos Horarios asociados (1:N, a nivel de tabla).
  Navegación ORM implementada:
  • Desde Horario hacia Pelicula: horario.pelicula.
  • No se ha definido en el ORM la colección inversa pelicula.horarios; la navegación se mantiene intencionadamente unidireccional.
• Horario ↔ Sala
  • Cada Horario referencia una única Sala mediante sala_id.
  • Una Sala puede tener múltiples Horarios (1:N, a nivel de modelo lógico).
• Horario ↔ Venta
  A nivel de base de datos:
  • La FK está en ventas.horario_id apuntando a horarios.id.
  A nivel lógico/ORM:
  • Un Horario puede tener muchas Ventas (1:N).
  • Cada Venta corresponde a un único Horario (N:1).

Servicios — Horarios

• Crear horario para una película en una sala
• Listar horarios por película
• Listar horarios por fecha
• Listar horarios por sala
• Editar horario (cambiar hora, sala, película)
• Cancelar horario (marcar como no disponible)

Extra (futuro)

• Comprobar solapamientos de horarios en la misma sala
• Mostrar solo sesiones futuras
• Control de aforo basado en ventas

💳 Venta

Responsable: IÑAKI

Representa la compra de entradas para un determinado horario.

Campos

• id: int — PK
• horario_id: int — FK → horarios.id
• precio_total: float
• cantidad: int (número de entradas)
• metodo_pago: enum (efectivo, tarjeta, cripto…)
• socio_id: int (opcional) — FK → socios.id

Relaciones (modelo y ORM)

• Venta ↔ Horario
  • Cada Venta está asociada a un único Horario mediante horario_id.
  • Un Horario puede tener múltiples Ventas asociadas.
• Venta ↔ Socio (opcional / futuro)
  • Cada Venta puede opcionalmente estar asociada a un Socio mediante socio_id.
  • Un Socio puede acumular muchas Ventas a su nombre.

Servicios — Ventas 💳

• Registrar venta
• Calcular precio total
• Listar ventas (por día, película, horario…)
• Consultar recaudación en un rango de fechas

Extra (futuro)

• Cupones de descuento
• Asignar venta a usuario o socio
• Generar ticket (PDF / código QR)

🏷️ Género

Responsable: KARY

Catálogo de géneros cinematográficos asociados a las películas.

Campos

• id: int — PK
• nombre: string
• descripcion: string

Relaciones (modelo y ORM)

• Género ↔ Pelicula
  • Cada Pelicula referencia un Genero mediante genero_id.
  • Cada Genero puede agrupar muchas Peliculas asociadas.

Servicios — Géneros 🏷️

• Crear género
• Listar géneros
• Editar género
• Eliminar género (según política de negocio)

Extra (futuro)

• Permitir múltiples géneros por película (tabla intermedia)
• Estadísticas por género (películas, ventas, horarios, etc.)

🔐 Login / Autenticación

Responsable: JAVIER CACHÓN

Sistema central de autenticación y autorización de usuarios (clientes y administradores).

Campos

• id: int — PK
• username: string (único)
• email: string (único)
• password_hash: string
• rol: enum (usuario, administrador)
• activo: boolean
• bloqueado: boolean
• creado_en: datetime
• actualizado_en: datetime

Relaciones (modelo y ORM)

• Login ↔ Socio
  Relación modelada típicamente como Optional One-to-One: la FK opcional reside en la tabla socios.
  • Un Socio puede vincularse a un único Login mediante login_id.
  • Un Login puede estar vinculado, como máximo, a un Socio.
  Esta relación permite: socios sin login (alta en taquilla) y logins sin socio (usuario registrado sin programa de puntos).

Servicios — Login 🔐

• Registrar usuario
• Iniciar sesión
• Cerrar sesión
• Cambiar contraseña
• Recuperar contraseña
• Bloquear / desbloquear cuenta
• Editar email o username
• Listar logins activos / bloqueados

Extra (futuro)

• Doble factor de autenticación (2FA)
• Historial de accesos (IP, fecha, dispositivo)
• Expiración periódica de contraseña

👥 Socio / Fidelización

Responsable: JAVIER CACHÓN

Sistema de clientes registrados con ventajas y programa de puntos.

Campos

• id: int — PK
• numero_socio: string
• login_id: int — (opcional) FK → logins.id
• email: string (único)
• nivel: enum (Basic, Silver, Gold, VIP)
• puntos: int
• fecha_alta: datetime
• activo: boolean

Relaciones (modelo y ORM)

• Socio ↔ Login
  • Cada Socio puede estar vinculado a un único Login (cuenta de acceso web).
  • Cada Login puede vincularse, como máximo, a un Socio.
• Socio ↔ Venta (opcional / futuro)
  • Un Socio puede tener asociadas múltiples Ventas (historial de compras).
  • Cada Venta puede referenciar al Socio que la realizó.

Servicios — Socios 👥

• Alta de socio
• Vincular socio con login
• Consultar perfil de socio
• Consultar puntos
• Upgrade/downgrade de nivel
• Sumar puntos (compras, promociones)
• Restar puntos (canjes, devoluciones)
• Baja de socio (marcar como inactivo)

Extra (futuro)

• Historial de puntos
• Ventajas por nivel (descuentos, preestrenos, etc.)
• Envío de promociones por email
• Tarjeta digital QR

🔗 Modelo de Datos y Relaciones (Cardinalidad)

A continuación se resumen las relaciones entre las entidades, indicando claves foráneas, dirección, cardinalidad y, cuando aplica, cómo se navega en el ORM.

2.1. Pelicula ↔ Género

• FK: peliculas.genero_id → generos.id
• Cardinalidad (modelo lógico):
  • Una Pelicula pertenece a un único Genero.
  • Un Genero puede tener muchas Peliculas.
• Tipo:
  • Pelicula → Genero: ManyToOne (N:1)
  • Genero → Pelicula: OneToMany (1:N)
• Navegación ORM típica: pelicula.genero y, si se define, genero.peliculas

2.2. Horario ↔ Pelicula

• FK: horarios.pelicula_id → peliculas.id
• Cardinalidad (modelo lógico):
  • Un Horario corresponde a una Pelicula concreta.
  • Una Pelicula puede tener muchos Horarios (1:N).
• Tipo:
  • Horario → Pelicula: ManyToOne (N:1)
  • Pelicula → Horario: OneToMany (1:N) (a nivel de diseño de datos)
• Navegación ORM implementada: solo horario.pelicula (no se implementa pelicula.horarios en el modelo actual).

2.3. Horario ↔ Sala

• FK: horarios.sala_id → salas.id
• Cardinalidad:
  • Un Horario se proyecta en una sola Sala.
  • Una Sala puede tener muchos Horarios.
• Tipo:
  • Horario → Sala: ManyToOne (N:1)
  • Sala → Horario: OneToMany (1:N)

2.4. Venta ↔ Horario

• FK: ventas.horario_id → horarios.id
• Cardinalidad:
  • Una Venta está asociada a un solo Horario.
  • Un Horario puede tener muchas Ventas.
• Tipo:
  • Venta → Horario: ManyToOne (N:1)
  • Horario → Venta: OneToMany (1:N)

2.5. Socio ↔ Login

• FK: socios.login_id → logins.id (opcional)
• Cardinalidad:
  • Un Socio puede estar vinculado a un solo Login.
  • Un Login puede estar vinculado, como máximo, a un Socio.
• Tipo:
  • Socio → Login: Optional OneToOne (0..1 : 1)
  • Login → Socio: Optional OneToOne (1 : 0..1)

2.6. Venta ↔ Socio (futuro)

(Opcional, si se implementa en el modelo)

• FK: ventas.socio_id → socios.id
• Cardinalidad:
  • Una Venta puede estar asociada a un Socio.
  • Un Socio puede tener muchas Ventas a lo largo del tiempo.
• Tipo:
  • Venta → Socio: ManyToOne (N:1)
  • Socio → Venta: OneToMany (1:N)

Resumen visual simplificado

generos (1) ────< (N) peliculas

peliculas (1) ────< (N) horarios >──── (1) salas

horarios (1) ────< (N) ventas

logins (1) ────(0..1) socios

socios (1) ────< (N) ventas    [opcional si se añade ventas.socio_id]
        

📦 Instalación de dependencias

Antes de ejecutar el proyecto se recomienda utilizar un entorno virtual de Python y cargar todas las dependencias desde requirements.txt.

1. Clonar el repositorio

git clone https://github.com/ojosdegato/Cartelera-de-cine-en-Python.git
cd Cartelera-de-cine-en-Python.git
        

2. Crear y activar entorno virtual (opcional, pero recomendado)

# Linux y MacOS
python3 -m venv .venv
source .venv/bin/activate

# Windows (PowerShell)
python -m venv .venv
.venv\Scripts\Activate.ps1
        

3. Instalar dependencias del proyecto

Con el entorno virtual activado:

pip install -r requirements.txt
        

Entre las dependencias típicas se incluyen paquetes como fastapi, uvicorn, sqlalchemy, pydantic jinja2 y el driver de sqlite ya incorporado en la librería estándar de Python.

▶️ Ejecución paso a paso

Una vez instaladas las dependencias y creada la base de datos, la ejecución del proyecto se realiza normalmente a través de FastAPI y un servidor ASGI como Uvicorn.

1. Comprobar variables de entorno (opcional)

Si se utilizan variables de entorno (por ejemplo, para el modo debug o la URL de la base de datos), configúralas antes de lanzar la aplicación.

2. Ejecutar el servidor de desarrollo

# Desde la raíz del proyecto
uvicorn app.main:app --reload
        

Por defecto, la API estará disponible en: http://127.0.0.1:8000 y la documentación interactiva en:

• http://127.0.0.1:8000/docs (Swagger UI)
• http://127.0.0.1:8000/redoc (ReDoc)

3. Ejecución desde run.py (alternativa)

python run.py
        

Este script puede actuar como punto de entrada unificado para entornos de desarrollo o despliegue.

🗄️ Scripts de inicialización de la base de datos

La base de datos principal del proyecto es un fichero SQLite llamado db.db, ubicado en app/database/.

1. Módulos de base de datos

• app/database/db.py — configuración de la conexión SQLAlchemy.
• app/database/db.py — creación de tablas y carga inicial de datos (seed).

2. Crear o recrear la base de datos

Desde la raíz del proyecto:

python -m app.db.db
        

Este script se encarga de:

• Crear el fichero db.db si no existe.
• Generar las tablas correspondientes a las entidades: peliculas, generos, salas, horarios, ventas, logins y socios.
• Cargar datos de ejemplo (películas, horarios, etc.) para pruebas.

3. Regenerar la base de datos (entornos de desarrollo)

En desarrollo es habitual borrar el fichero db.db y volver a ejecutar python -m app.db.db para partir de un estado limpio.

🌐 Definición de endpoints con FastAPI

La API se estructura en módulos de rutas dentro del paquete app/routes/, separando por dominio funcional (películas, géneros, salas, horarios, ventas, socios y login).

1. Punto de entrada de la API: app/main.py

from fastapi import FastAPI
from app.routes import peliculas, generos, salas, horarios, ventas, socios, login

app = FastAPI(title="Cartelera de Cine en Python")

app.include_router(peliculas.router, prefix="/peliculas", tags=["Películas"])
app.include_router(generos.router,   prefix="/generos",   tags=["Géneros"])
app.include_router(salas.router,     prefix="/salas",     tags=["Salas"])
app.include_router(horarios.router,  prefix="/horarios",  tags=["Horarios"])
app.include_router(ventas.router,    prefix="/ventas",    tags=["Ventas"])
app.include_router(socios.router,    prefix="/socios",    tags=["Socios"])
app.include_router(login.router,     prefix="/auth",      tags=["Login"])
        

2. Ejemplo de endpoints: app/routes/peliculas.py

from fastapi import APIRouter, HTTPException
from typing import List
from app.schemas.pelicula import PeliculaCreate, PeliculaRead
from app.services.peliculas import PeliculaService

router = APIRouter()

@router.get("/", response_model=List[PeliculaRead])
def listar_peliculas():
    return PeliculaService.listar()

@router.get("/{pelicula_id}", response_model=PeliculaRead)
def obtener_pelicula(pelicula_id: int):
    pelicula = PeliculaService.obtener(pelicula_id)
    if not pelicula:
        raise HTTPException(status_code=404, detail="Película no encontrada")
    return pelicula

@router.post("/", response_model=PeliculaRead, status_code=201)
def crear_pelicula(datos: PeliculaCreate):
    return PeliculaService.crear(datos)

@router.delete("/{pelicula_id}", status_code=204)
def eliminar_pelicula(pelicula_id: int):
    PeliculaService.eliminar(pelicula_id)
        

3. Endpoints habituales por módulo

• /peliculas: CRUD de películas y filtros por género, disponibilidad, etc.
• /generos: mantenimiento del catálogo de géneros.
• /salas: gestión de salas y capacidades.
• /horarios: gestión de sesiones (película + sala + hora).
• /ventas: registro de ventas y consultas de recaudación.
• /socios: alta, baja y gestión de datos de socios.
• /auth: registro, login, logout y gestión de credenciales.

Esta organización facilita el mantenimiento, la escalabilidad del proyecto y la integración posterior con un frontend (por ejemplo, una SPA o plantillas Jinja2).

🚀 Futuras Mejoras del Proyecto

• Sistema completo de compra de entradas (frontend + backend).
• Diseño gráfico tipo cine (UI/UX más cinematográfica).
• Panel de administración web (gestión de contenidos y usuarios).
• Estadísticas avanzadas (ventas, ocupación, popularidad de películas).
• Machine Learning para recomendaciones personalizadas de películas.

📦 Próximas actualizaciones

Se incorporará documentación detallada y ejemplos adicionales sobre:

• Estructura de carpetas del proyecto.
• Instalación de dependencias en distintos entornos.
• Ejecución paso a paso con distintos perfiles (desarrollo / producción).
• Scripts de inicialización y migraciones de la base de datos.
• Definición avanzada de endpoints y seguridad en FastAPI.

✨ Proyecto en constante evolución. Cada aportación suma. Este repositorio seguirá creciendo con nuevas funcionalidades, mejoras y buenas prácticas de programación.

Compartiendo el codigo abierto del proyecto

El 19 de diciembre 2025 terminamos la presentación del proyecto a empresas y finalizamos curso. Compartire el código fuente licencia GPL3 en navidades. ¡Espero terminar las navidades y empezar un prospero año 2026 con empleo de programador junior!