Introducción
Estos últimos cuatro meses, encaramos un proyecto bastante grande a como veníamos trabajando en los últimos 4 años de facultad. La consigna principal era simular un ambiente de trabajo para un junior/trainee, es decir, uno llega y se encuentra con miles de cosas por aprender y aplicar en poco tiempo.
El proyecto constaba de realizar una aplicación mobile utilizando una arquitectura de microservicios, ésta debía estar implementada en al menos dos lenguajes de programación diferentes y utilizando dos tipos de bases de datos distintas. Sumado a esto, debíamos desarrollar un panel de administradores web.
En el equipo eramos 5 personas, todos sin experiencia previa de ese nivel. Estas son las cosas que observe y aprendi, por afuera de lo desarrollado.
Compromiso de equipo
Comenzamos proponiendo en un Notions diferentes convenciones que íbamos a utilizar para poder estar todos alineados, en las primeras semanas preparamos los repositorios y propusimos utilizar los Boards que permite GitHub utilizando las diferentes Historias de Usuarios como Issues.
La principal observación que vi es que es muy difícil generar que cada integrante del equipo siga a raja tabla el proceso, como se refleja esto? Principalmente se pueden ver Issues cerradas pero sin estar en el board, branches muertas y falta de milestones en cada semana de desarrollo.
Tecnologias
Como equipo, nos encontramos que debiamos aprender muchisimas cosas nuevas en poco tiempo, como siempre, al ser la primera vez las cosas cuestan mucho mas. No tuvimos problema en aprender las herramientas nuevas, si confieso que a mi parecer la inexperiencia hacia que varias implementaciones sean rústicas, pero creo que eso va mejorando a medida que uno desarrolla y usa aquella tecnología cada vez mas.
En nuestro caso utilizamos.
- Python - Fast API
- NodeJS - Express
- Postregs SQL
- MongoDB
- Firebase
- Datalog
- React Native
- Expo
- React
Despliegue y Testing
Desarrollar utilizando TDD es algo de lo que venimos haciendo hace varios cuatrimestre, son pocos los que de verdad siguen aplicando test, muchos para safar implementa a prueba y error. Esto es algo común en aplicaciones de consola pequeñas, pero en una app web mas grande es algo arriesgado, es por eso que nos propusimos testear lo que mas se pueda.
Para el despliegue utilizamos Okteto, que utiliza kubernetes y a partir de un docker-compose.yml levanta el ambiente. Tiene una versión FREE que para nuestro proyecto la verdad que venia excelente.
Tuvimos dos ambientes, el local, utilizando contenedores de Docker y el de producción. Hubiera sido eficiente también tener uno de test.
Una cosa que notamos positiva de los microservicios, es que teníamos quizás alguno caído pero como la aplicación no lo utilizaba, esta podía estar funcionando correctamente, lo cual con un monolito esto no es posible.
Desarrollo
Para completar con lo pedido planteamos una arquitectura de 5 servicios + una API GATEWAY
Al estar trabajando con microservicios, podíamos dividirnos los servicios y avanzar mucho mas rápido que al ser un monolito.
La complicación estaba en la conexión de datos entre servicio. Con esto quiero decir que las restricciones de las claves foráneas entre servicio es algo a tomar con pinzas, a diferencia de un monolito que solo utiliza una db.
La seguridad también fue algo a tener en cuenta ya que todos los servicios tenían que estar alineados para entender los mismo JWT que tenia el usuario.
Utilizamos firebase para la autenticación segura. Al principio nos complicó la extensa documentación que tiene pero le pudimos agarrar la mano.
Aqui se ve el flujo que utilizamos para el servicio de administradores.
Conclusión
Creo que hicimos un buen trabajo, pusimos mucho esfuerzo y compromiso, logramos cumplir con las historias de usuarios obligatorias del trabajo y muchas electivas que aportaban usabilidad.
Quedaron algunas deudas técnicas para un futuro pero la aplicación quedo bastante buena y como equipo, estamos orgullosos de nuestro trabajo.
Top comments (0)