Proyecto Curso — Control de Gastos con IA Generativa

Backend de control de gastos personales, construido durante el curso. Arquitectura: monolito modular + capas + Repository.

Reflexión (Paso 5)

1. ¿Qué cambiaría si agrego un repository que guarde en JSON? En services/gastos.py, nada — ninguna línea de _validar_gasto ni de registrar_gasto/listar_gastos cambia, porque el service depende de la abstracción "objeto con guardar, listar, total_por_categoria" (DIP), no de la implementación concreta en memoria. Solo se crearía un nuevo módulo (p. ej. app/repositories/gastos_json.py) con esos mismos tres métodos, y se pasaría como repo=... al llamar al service (o se cambiaría el valor por defecto).

2. "Voy a poner la validación del monto directo en el router": rompe SRP y la arquitectura en capas — el router debe recibir la solicitud, no decidir reglas de negocio. Si la validación vive en el router, queda duplicada o inconsistente en cualquier otro lugar que también llame a registrar_gasto (otro endpoint, un tool de MCP en la Sesión 8, un test), y ya no se puede probar esa regla sin levantar el framework web. Al dejarla en _validar_gasto dentro de services/, se prueba con un simple pytest, sin mocks ni servidor, tal como hicimos hoy.

Cierre

"Hoy pude probar mi lógica de negocio sin levantar infraestructura real (sin base de datos, sin mocks de librerías), gracias a la inversión de dependencias (DIP): el service recibe el repository como parámetro, así que en los tests le inyecté un RepositorioFalso con el mismo contrato."

Sesión 7 — De la arquitectura al código

Repository en memoria reemplazado por SQLAlchemy + Alembic (SQLite), autenticación OAuth2 + JWT, hashing de contraseñas con passlib/bcrypt, schemas Pydantic y routers REST protegidos.

Nota sobre passlib + bcrypt: bcrypt>=4.1 rompe con passlib==1.7.4 (lee un atributo interno que ya no existe). Se fijó bcrypt<4.1 con uv add "bcrypt<4.1", tal como advierte el propio enunciado, y hash_password/verify_password funcionan correctamente.

Hallazgo respecto al enunciado: el checkpoint del Paso 9 dice que tests/test_gastos.py de la Sesión 6 "sigue pasando tal cual" — no es exacto. registrar_gasto/listar_gastos ahora llaman a repo.total_por_categoria(db, usuario_id, categoria), repo.guardar(db, usuario_id, ...) y repo.listar(db, usuario_id, skip, limit), con nuevos parámetros db y usuario_id. Se actualizó RepositorioFalso (y las llamadas en los 4 tests) a esa misma firma — pasando None/1 como placeholders que el doble ignora — para que sigan cumpliendo el mismo contrato que el repository real, sin usar unittest.mock. _validar_gasto en sí no cambió ni una línea, que es la parte que el enunciado sí cumple.

Reflexión (Paso 12)

1. ¿Qué archivo tocaría para migrar SQLite → Postgres? Solo DATABASE_URL en .env (y el driver en pyproject.toml, p. ej. psycopg). app/database.py no cambiaría de código (usa settings.database_url genéricamente), salvo quitar connect_args={"check_same_thread": False}, que es específico de SQLite. NO tocaría models/, schemas/, services/, repositories/ ni routers/ — todos hablan en términos de sesiones de SQLAlchemy, no de SQLite.

2. ¿Podría alguien ver gastos de otro usuario pasando usuario_id en la URL? No, con el código de hoy no existe esa vía: GET /gastos/ no lee usuario_id de la URL ni del query string en ningún punto — lo obtiene siempre de usuario_actual.id, que sale del JWT verificado en get_current_user (app/dependencies.py). Un atacante tendría que falsificar un token válido firmado con el SECRET_KEY del servidor, no simplemente cambiar un parámetro en la URL.

Cierre

"Si mañana un atacante consigue mi archivo .env, podría firmar tokens JWT válidos para cualquier usuario (tiene el SECRET_KEY) y leer DATABASE_URL, pero NO podría recuperar las contraseñas originales de los usuarios, porque solo se guarda hashed_password (hash de bcrypt con salt, de un solo sentido) — nunca la contraseña en texto plano."

Sesión 8 — Del backend a los agentes

app/mcp/ deja de estar vacía: servidor MCP (app/mcp/server.py) con dos tools — registrar_gasto y listar_gastos (app/mcp/tools/gastos.py) — que llaman directo a app/services/gastos.py, el mismo que usa el router REST. services/gastos.py y repositories/gastos.py no cambiaron ni una línea desde la Sesión 7 (verificado con git diff --stat 507058a -- app/services/gastos.py app/repositories/gastos.py, sin salida).

Dependencia: uv add "mcp[cli]<2". El SDK instala por defecto mcp 2.x, que renombró FastMCP a MCPServer y no expone mcp.server.fastmcp — el mismo tipo de incompatibilidad de versión que bcrypt/passlib en la Sesión 7. Se fijó <2 para usar el código del enunciado tal cual.

Dos bugs reales encontrados y corregidos, reproducidos con el comando exacto del enunciado (uv run mcp dev app/mcp/server.py):

1. Doble instancia de FastMCP. El patrón del enunciado (tools/gastos.py hace from app.mcp.server import mcp) rompe cuando el CLI de mcp carga server.py como script standalone: ese import de vuelta por la ruta del paquete (app.mcp.server) re-ejecuta el archivo y crea una segunda instancia de FastMCP, distinta de la que el CLI corre. Los tools quedan registrados en la instancia "fantasma"; el cliente ve list_tools() vacío y Unknown tool al intentar llamarlos. Verificado con id(): dos objetos FastMCP distintos en memoria. Fix aplicado: tools/gastos.py expone register(mcp) en vez de importar mcp; server.py crea la instancia y llama gastos.register(mcp) explícitamente. Ningún archivo se reimporta a sí mismo por una ruta distinta.

2. ModuleNotFoundError: No module named 'app'. El ejecutable mcp (entry-point de consola en .venv/bin/) no agrega la raíz del proyecto a sys.path, a diferencia de python -m app.main. El proyecto no está declarado como paquete instalable, así que app no es importable fuera del directorio de trabajo. Fix: anteponer PYTHONPATH=. al comando, ej. PYTHONPATH=. uv run mcp dev app/mcp/server.py.

Verificación e2e real (sin mocks, protocolo MCP por stdio): un cliente ClientSession de la SDK, conectado al servidor vía uv run mcp run app/mcp/server.py con PYTHONPATH=., confirmó los 4 pasos del enunciado: list_tools() devuelve los 2 tools con sus descripciones; registrar_gasto("Almuerzo", 12.50, "comida") crea el gasto; listar_gastos() lo devuelve; registrar_gasto con categoria="inventada" responde {"error": "'inventada' no es una categoría válida"} sin stack trace.

Reflexión

1. _obtener_o_crear_usuario_demo con varios usuarios reales: se rompería primero el aislamiento de datos — todos los clientes MCP compartirían el mismo usuario_id (el del email fijo demo@curso.com), así que cualquiera vería y modificaría los gastos de cualquier otro. Es exactamente el problema que el JWT resuelve en REST desde la Sesión 7; en MCP falta el equivalente (identidad propagada por el transporte/cliente).

2. ¿Qué habría estado mal en la Sesión 6 para tener que tocar services/gastos.py hoy? Que registrar_gasto/listar_gastos dependieran directamente de app.repositories.gastos (import fijo) en vez de recibir repo como parámetro (DIP), o que la validación de negocio (_validar_gasto) viviera en el router/repository en lugar de en services/. Con cualquiera de los dos, el tool de MCP no habría podido reutilizar la lógica sin copiarla o sin acoplarse a FastAPI.

Cierre

"Hoy construí una tercera puerta de entrada al mismo backend. Lo que NO tuve que duplicar fue la lógica de negocio (_validar_gasto, registrar_gasto, listar_gastos), y eso fue posible gracias a DIP y a la separación en capas (decisión que tomamos en la Sesión 6)."