E180 - Vibecodeando la casa de apuestas de en_coders con FastAPI

Resumen

En este episodio Mati presenta una app que construyó "vibecodeando" con un LLM: una casa de apuestas casera tipo Polymarket hecha con FastAPI, pensada como juego interno de oficina. La app está desplegada en línea (Render, plan gratuito) y usa SQLite con SQLAlchemy y autenticación con tokens JWT. Mati explica con sus palabras los conceptos que tuvo que aprender: cliente/servidor, métodos GET y POST, códigos de error, Swagger, tablas y relaciones, helpers, Pydantic y tipado fuerte. También repasa el modelo de precios LMSR y hace pruebas en vivo, algunas fallidas. Las conclusiones son que entender el código generado toma mucho más tiempo que generarlo, que los data scientists deben aprender conceptos de ingeniería de software y que Pydantic resulta muy útil. Quedan pendientes un método para borrar mercados, la inflación al crear usuarios y reglas claras para resolver las apuestas.

Capítulos

• 00:00
  IntroSe presenta el episodio 180 sobre una app FastAPI de Mati, ajena al data science y hecha como autoestudio. Mati dice que vibecodeó la app y que tardó menos en generarla que en entender lo que hizo.
• 04:30
  Origen del proyecto de casa de apuestasEl proyecto nace de la curiosidad por Polymarket y de una broma interna de la oficina. Mati usa FastAPI porque en su trabajo lo usan, y dice que quiere aprender los conceptos de software que antes no necesitaba. Cris comenta que hoy un ingeniero debe cubrir muchas áreas con ayuda de los LLM.
• 09:01
  Demo del Polymarket caseroMuestra la página desplegada en Render, que se cayó brevemente por el plan gratuito. Solo el admin crea cuentas y cualquier usuario logueado puede crear apuestas. Los tokens duran 3 meses y se parte con 1000 "coder coins".
• 13:44
  Juego interno de oficinaLa idea es dar monedas cada mes, como un sueldo (por ejemplo 10.000), para apostar, con posibles premios a nivel de equipo. Es solo una broma para el equipo y por ahora solo admite apuestas de sí o no, sin opciones múltiples.
• 16:57
  Cómo lo construí con LLMSu prompt inicial pedía un modelo LMSR, monedas virtuales y un monolito sin arquitectura compleja. El LLM creó primero solo el backend. El front (HTML con JavaScript incrustado) lo fue modificando copiando y pegando código en ChatGPT.
• 18:02
  Swagger y endpoints básicosDescubre que la página que mostró el backend era Swagger, que FastAPI genera solo. Mati usa diapositivas también hechas con el LLM. El código final tiene unas 500 líneas.
• 22:09
  GET vs POST y erroresExplica el modelo cliente-servidor por HTTP con respuestas en JSON. GET lee y POST modifica, y hay otros métodos como head, put y delete. Cuenta que las rutas se definen con decoradores, repasa los códigos de error (200, 404) y el vocabulario body/JSON/payload. Se menciona el código 418 "soy una tetera".
• 31:46
  Auth y crear usuarios en vivoEn Swagger intenta crear un usuario sin estar autenticado y recibe 401. Crea un admin con un token, luego crea el usuario de Cris y la app lo muestra. Cris crea una apuesta de prueba en la app desplegada.
• 37:16
  SQLiteExplica que SQLAlchemy permite manejar la base de datos con objetos Python en lugar de queries SQL. Cuenta que viene de cursos de bases de datos nulos y que imaginó la base como tablas "viviendo" en algún lado.
• 39:59
  DDLLee la tabla users: id como primary key, email, password hasheada, rol (user o admin) y display name. Agregar una columna obligó a borrar y recrear la base, y Mati se pregunta cómo se hace eso con datos reales. Se comenta que en SQL el diseño de tablas es fijo y se planifica mucho.
• 42:50
  Consultas y dependenciasEntiende que `Depends(get_db)` sirve para obtener la sesión de base de datos. Una query con SQLAlchemy equivale a la consulta SQL, por ejemplo filtrar por rol admin.
• 44:00
  Relaciones y tablas claveDescribe cinco tablas: usuarios, wallets, mercados, posiciones y transacciones. Un usuario puede tener varias posiciones (relación 1 a N), y los endpoints POST solo modifican estas tablas.
• 48:25
  MemesSe comenta un video repetido con distinto autor y vistas muy distintas, el acrónimo "e don't bre" y el archivo Soul.md de OpenClaw. También se habla de dar acceso permanente a la terminal a Claude Code y de una lista de métodos HTTP.
• 57:21
  Credenciales y JWT tokensCrea usuarios para el chat (Rodo) y explica que las contraseñas se guardan hasheadas, por lo que no se pueden recuperar, solo cambiar. Cris y otros comentan que los hashes no son biyectivos y que las colisiones son improbables.
• 01:00:32
  Helpers y autenticaciónLos helpers hashean y verifican contraseñas, generan y decodifican el token y obtienen el usuario autenticado. `require_admin` comprueba el rol. Mati pidió un monolito dividido en secciones, y Cris explica que los helpers se usan para no repetir lógica.
• 01:09:30
  Pydantic y tipado fuertePydantic define "contratos" (esquemas) para entrada y salida, como un email, una contraseña de mínimo 6 caracteres y un display name opcional. Se aclara que el tipado de Python por defecto no es estricto y que Pydantic sí lo exige.
• 01:14:03
  Validación de emailEn vivo, un email inválido devuelve el error 422, y una contraseña corta también falla gracias a Pydantic con `EmailStr`.
• 01:16:07
  Precios dinámicos de sharesLos precios suben a medida que se compra. Cada share tiene su propio precio, se pueden comprar fracciones y la compra de 100 shares cuesta unos 64 coins. Si el mercado se resuelve a favor, cada share paga una coin. Se propone un botón de confirmación y mostrar el costo antes de comprar.
• 01:22:53
  LMSRExplica que el nombre es Logarithmic Market Scoring Rule. La pérdida máxima de la casa está acotada por b·ln(n), y el costo viene de una derivada con logaritmo. El detalle se vio en el episodio 173. Mati descubre que le falta un endpoint para borrar mercados.
• 01:25:44
  Endpoints y creación de usuarioRecorre el endpoint de crear usuario: valida al admin, crea el usuario y su wallet con el balance inicial, y hace commit o rollback ante un error de integridad, por ejemplo con un email duplicado.
• 01:30:04
  Return y respuesta de la APISe discute para qué sirve el return del endpoint. Queda claro que define la respuesta que se ve en el frontend y en Swagger, aunque la app funcionaría sin él. Mati pierde el token de admin y la demo en vivo falla.
• 01:36:00
  Frameworks y estados en frontendMati no leyó el front y solo preguntó por qué se usan frameworks como React. Le respondieron que sirven cuando escala el manejo de muchos estados. Cree que en su trabajo verá más backend y microservicios.
• 01:40:17
  Lecciones y próximos pasosComenta que una apuesta se perdió por una comilla faltante detectada gracias a Pydantic. Plantea la inflación al crear usuarios y la necesidad de reglas claras para resolver apuestas. Dice que el ejercicio le tomó unas 3 horas y bastante más entender el código, y recomienda aprender estos conceptos.
• 01:44:21
  CierreAnuncian una posible entrevista la semana siguiente, piden like y suscripción, y mencionan el Discord.

Palabras clave