Gymnastic Center

Mobile fitness companion

Revisa el código:

La historia

En la universidad cursé una materia fascinante llamada Desarrollo de Software. En este curso, se estudian patrones de diseño y arquitecturas limpias para la construcción de software limpio, mantenible y testeable. Específicamente, aprendimos sobre la arquitectura hexagonal, Domain Driven Design (DDD) y Aspect Oriented Programming (AOP).

Para aplicar los conceptos aprendidos, nos asignaron a realizar una aplicación móvil de fitness. Los requerimientos eran vagos e incompletos, era nuestro trabajo diseñar y construir una solución de software que cumpla con los requerimientos del cliente (el profesor) y que siga las buenas prácticas mencionadas anteriormente.

Eran 4 equipos de 12 personas en promedio. Naturalmente se creó un ambiente competitivo para ver cual equipo construiría la mejor aplicación. Al final, gracias a nuestro enfoque al UX y a proveer un producto real y usable, ganamos la competencia.

Un vistazo a la app

Los usuarios pueden ingresar y ver cursos y blogs relacionados a fitness. Pueden filtrar por categoría o instructor. Pueden hacer comentarios y preguntas, dejar likes/dislikes y traquear su progreso en cada curso.

Selector de APIs

Para garantizar la calidad de nuestro software, el profesor nos puso un requerimiento a nuestros backend. El backend de un equipo debe ser compatible con el front de otro, es decir, los backend deben ser intercambiables. Esto nos obligo a crear un API estándar y cada equipo debe seguirlo. Entonces el dia de la entrega, debemos poder cambiarnos al backend de otro equipo rápidamente.

Los otros equipos lo que hacían era tumbar la aplicación, cambiar el url del backend y volver a correr la app. Nosotros queríamos hacer que este cambio sea una funcionalidad más de la app.

Lo que hicimos fue guardar el url del API en el estado global de la aplicación, y cambiarla desde la pantalla de inicio de sesión para ingresar en la app y ver el contenido del equipo que quisiéramos (nosotros eramos Omega).

Tecnologías usadas

La aplicación esta conformada en dos partes (frontend y backend). En el frontend se usa Flutter, un framework de Dart creado por Google para construir aplicaciones nativas a distintas plataformas con un solo codebase, ahorrando mucho tiempo de desarrollo.

Para el backend, se usa NestJS un framework de Node para crear servidores escalables y seguros. Para la base de datos, mongoDB, una cola de RabbitMQ para la sincronización de los read models, se desarrollo un sistema de búsquedas y recomendaciones con Algolia y se aplicaron patrones arquitectónicos como DDD, Arq Hexagonal, CQRS y Event Sourcing.