Bynle

Cliente

React, con React Router protegiendo las rutas privadas y un árbol de rutas aparte para las cuentas de escáner.

Aplicación

Vistas REST de Django agrupadas en diez manejadores de dominio, con serializadores para la validación y la conversión a JSON.

Datos

PostgreSQL para los datos estructurados, ejecutado desde una imagen de Docker; un bucket de S3 para los archivos subidos.

Integración

Stripe para los pagos y el alta en Connect, con una comprobación de estado que decide si un club o un usuario puede cobrar.

Despliegue

Railway para el backend y la base de datos, AWS Amplify para el frontend y control de versiones con Git para ambos.

Las pruebas fueron por tres vías: revisión de código en cada merge request, pruebas unitarias del backend y sesiones de prueba con estudiantes reales.

El backend terminó con 134 pruebas unitarias entre modelos y vistas: integridad de datos y reglas de validación por un lado, gestión de peticiones y lógica de negocio por otro, incluidas comprobaciones de permisos como confirmar que solo una cuenta de escáner puede acceder al endpoint de validación de entradas. Ningún cambio llegó a la rama principal sin que lo revisara el otro.

Las pruebas con usuarios cambiaron el producto. Dos peticiones se repitieron con claridad suficiente como para construirlas:

• Una campana de notificaciones. Los usuarios querían llegar a las solicitudes de amistad y a las transferencias entrantes desde cualquier punto, y no navegando hasta la página que las contenía. Añadimos una campana en la barra superior, con un contador.
• Borrar una cesión enviada. Los participantes querían retirar una cesión enviada por error o tras un cambio de planes. Las transferencias enviadas pasaron a poder eliminarse.

Qué se rompió

1. 01

   Los administradores de club, modelados como clase propia

   Problema

   Los administradores de club empezaron siendo una clase de modelo dedicada. Era la forma equivocada: la relación entre usuarios y clubes es de muchos a muchos, y forzarla a través de una clase propia hacía incómoda la administración.

   Solución

   Se refactorizó a una relación de muchos a muchos, que permitió que varios usuarios administraran varios clubes sin ceremonias y simplificó todo el proceso.

2. 02

   Dos personas, migraciones borradas y una base de datos rota

   Problema

   Al principio trabajábamos en ramas separadas y ambos generábamos migraciones al cambiar los modelos. Ninguno entendía las migraciones de Django lo suficiente, y los dos habíamos borrado algunas. Al hacer rebase para fusionar con main, la base de datos se rompió: ya no coincidía con los modelos, y tardamos mucho en descubrir por qué.

   Solución

   Acordamos no volver a borrar una migración salvo con la base de datos respaldada y un borrado completo realmente justificado. Un script que repoblaba la base de datos desde cero nos permitió reconstruir un conjunto de datos funcional mientras lo resolvíamos.

3. 03

   Las entradas seguían siendo válidas durante la cesión

   Problema

   Mientras una transferencia estaba en curso, la entrada seguía activa, con el riesgo de un acceso no autorizado con una entrada que ya se estaba cediendo.

   Solución

   Las entradas mantienen un estado de transferencia hasta que el destinatario acepta o el remitente cancela. En ese estado no pueden escanearse y cuentan como inválidas en la puerta.

4. 04

   Desplegar tres piezas a la vez

   Problema

   Poner en producción el backend de Django, el frontend de React y la base de datos a la vez costó días de documentación y una larga racha de intentos fallidos en el servidor del backend.

   Solución

   Railway, que se integra con el repositorio y descarga la última versión de una rama fija, levantó el backend y la base de datos en una instancia compartida; el frontend se fue a AWS Amplify.