Introducción a la API de Gestión de Tareas de Usuarios 🚀

Hola, ¿qué tal?

Soy Jesús Robles, ingeniero de software, y vamos a dar una introducción a la API de gestión de tareas de usuarios como parte de la resolución de un challenge propuesto por Poole.

Las tecnologías que se están utilizando son Node.js, NestJS, TypeScript y Postgres como base de datos.

Adicionalmente decidí utilizar un ORM que es Prisma.

Ya que es un ORM actual y de fácil manejo que nos permite generar tipados y así como una gestión de migración de la base de datos, además de class validator y class transformer para la validación y transformación de datos que estamos recibiendo en los endpoints.

Como parte de la arquitectura, tenemos una arquitectura modular, la cual nos va a permitir dividir nuestra aplicación en pequeños módulos.

Esto me permite seguir principios SOLID, manteniendo una separación de responsabilidades y facilitando la escalabilidad del sistema.

Si deseamos extender el código, podemos hacerlo sin modificar el código existente y agregando más módulos conforme lo vayamos necesitando.

En este caso los módulos son users, tasks y analytics.

Cada uno de nuestros módulos contiene controllers, los cuales van a exponer las rutas de nuestros endpoints y manejar las peticiones de estos mismos, y así como servicios, los cuales manejan la lógica de negocio y el acceso a los datos a través de Prisma.

Y por último, si es necesario, contienen DTOs, los cuales nos permiten validar los datos que recibimos en las peticiones.

En la parte del modelado de datos tenemos la tabla usuario, la tabla tareas y la tabla asignación de tareas, ya que la idea principal fue poder asignar una— múltiples usuarios a múltiples tareas y además guardar la información adicional de esta relación como las horas trabajadas.

Por eso se utiliza una relación de muchos a muchos.

Cada una de las tablas contiene índices que se pueden observar en el esquema de la base de datos, los cuales implementé de acuerdo a los filtros solicitados en el challenge.

Estos nos ayudan a optimizar nuestras consultas en la base de datos, y también utilicé una relación, con una tabla intermedia para poder almacenar información adicional como las horas trabajadas, lo cual permite generar analíticas más especializadas sobre el desempeño del equipo.

También nos permite flexibilidad para asignar múltiples usuarios a las tareas y permite guardar métricas por usuario dentro de la tarea.

En la parte de la instalación tenemos dos opciones.

La opción uno y recomendada es usando Docker Compose, lo cual simplemente tenemos que clonar nuestro repositorio y movernos a la carpeta del repositorio.

Después tenemos que correr el comando de Docker Compose, el cual va a levantar un contenedor por Postgres, que es nuestra base de datos.

A construir nuestra API en NestJS, ejecutar migraciones de Prisma y ejecutar un pequeño seed que va a prellenar nuestra base de datos para poder hacer pruebas de esta misma.

Y por último se va a iniciar en el puerto 3000.

Y ya, eso es lo único que tenemos que hacer.

Nuestra API va a estar funcionando y de igual manera, lo hacemos de una manera fácil y sencilla.

Como dato extra, también disponemos de nuestra documentación en Swagger donde vamos a poder también probar de una manera muy rápida cómo desarrollar.

En la parte de los endpoints tenemos los solicitados, que es users, tasks y analytics, cada uno con sus filtros solicitados.

En la parte de tasks elegí el método PATCH, ya que solo vamos a modificar algunos campos del objeto, no vamos a modificar todo el objeto en sí.

Lo que me gustaría destacar es el endpoint de Analytics.

Este endpoint eligió optar por 3 propuestas.

La primera propuesta son métricas generales del estado de las tareas: el total de tareas, de las activas, de las completadas, de las vencidas, el costo total de las tareas, el promedio de horas estimado por tareas.

Como segunda métrica son los top users ¿Qué son los usuarios más productivos?

A través— esto lo calculamos a través del número de tareas completadas.

Y por último tenemos una métrica de distribución de trabajo por tareas.

En esta, en el promedio nos va a decir cuánto trabajo— bueno, sí, cuánto trabaja en promedio el usuario.

La suma nos muestra cuántas horas se trabajan en total, y la desviación estándar, que es lo importante, nos indica qué tan parejo o disparejo está el trabajo.

Si es baja, el trabajo está bien distribuido.

Si es alta, el trabajo está mal distribuido.

No solo es un cálculo, también lo convierto en algo útil que analizar teniendo perspectivas.

Por ejemplo, en este caso tenemos lo— variance, que es trabajo bien balanceado, medium variance, que es distribución normal, y high variance, que es distribución desigual.

Es importante saber si un equipo está sobrecargando a alguien para tomar acción en ello, además de detectar tareas mal distribuidas y también mejorar la asignación de trabajo.

No solo son métricas, sino son perspectivas que nos ayudan a entender cómo se está distribuyendo el trabajo en el equipo.

Y bueno, esto sería todo por mi parte.

Muchas gracias por el tiempo y la oportunidad de participar en este challenge.

Queda atento a cualquier duda o retroalimentación.