tucole.pe es una plataforma de repaso para estudiantes de 4.º y 5.º de secundaria: siete cursos, lecciones por unidad y exámenes, con la idea de que estudiar se parezca más a un juego que a un cuaderno.
Un detalle que conviene aclarar porque confunde a medio mundo, incluido a mí: tucole.pe no tiene relación con colegios.pe, aunque los dos hablen de educación y los dos hayan pasado por el mismo servidor viejo. Son productos distintos.
El problema real era el stack, no el producto
El producto funcionaba. El problema era que estaba construido sobre Django 3.0, Python 3.8, Vue 2 y Graphene, cuatro piezas sin soporte. Actualizar eso pieza por pieza cuesta más que reescribir cuando el dominio es pequeño, y este lo es:
| Pieza | Tamaño |
|---|---|
| Backend | 827 líneas, 6 modelos, 4 queries y 3 mutations GraphQL |
| Frontend | 2.708 líneas de Vue 2, 7 páginas, 6 operaciones |
| Datos | 7 cursos, sus unidades y sus preguntas |
Con ese tamaño, la decisión fue clara: reescribir. Un pip install de Django 3 a la versión actual, con Vue 2 por delante, habría dejado un código que nadie quiere mantener y un frontend que igual hay que tirar.
La estrategia: legado y nuevo en paralelo
Lo primero no fue escribir código, fue no romper nada. El legado siguió vivo en dev.tucole.pe mientras el stack nuevo se levantaba al lado, en su propio puerto y con su propia base de datos. Solo cuando el nuevo respondió igual que el viejo se hizo el corte.
Eso obliga a dos disciplinas:
- Una sola fuente de verdad por entorno. El nuevo no lee la base del viejo; se migran los datos y se comparan.
- Un criterio de corte explícito. No "cuando parezca que está", sino una lista de rutas y flujos que tienen que responder igual.
El stack nuevo
- API: FastAPI, SQLAlchemy 2, Alembic y PostgreSQL 18, con
psycopg3. Endpoints REST para cursos, unidades, lecciones, preguntas, autenticación y newsletter. Panel de administración con SQLAdmin para no escribir un CRUD a mano. - Web: SvelteKit con Svelte 5, TypeScript y Tailwind. Rutas para cursos, unidades, lección, examen, registro, login, preguntas frecuentes y páginas legales.
- Despliegue: dos servicios de systemd —API y web— detrás de nginx, que manda
/apia uno y/al otro.wwwredirige al dominio principal. Respaldos diarios conpg_dumpy 14 días de retención.
Lo que aprendí
El tamaño es una decisión, no una excusa. 827 líneas de backend no justifican una migración incremental de tres meses. Cuando el dominio es pequeño, reescribir es la opción conservadora, no la temeraria.
Las dependencias muertas se acumulan solas. Había configuración de S3 y Cognito para subir archivos que la aplicación nunca subió. Al reescribir, eso desaparece: si una pieza no tiene un caso de uso, no entra.
El corte es lo que da miedo, no el código. Tener el legado en paralelo y una lista de rutas que deben responder igual convierte el lanzamiento en una comprobación, no en una apuesta.
Estado
En producción en tucole.pe con el stack nuevo, con respaldos diarios y el legado archivado en solo lectura por si hace falta consultar algo.
Puedes ver el resto de mis proyectos.
Comentarios !
comments powered by Disqus