Tech & Experiences Vol. 3
Tech & Experiences es la forma relámpago en la que la comunidad techie de Flux IT comparte sus experiencias y aprendizajes más jugosos de proyectos en múltiples industrias.
Manejo de estados en una start-up
Por Iván Dackiewicz, Solution Architect
Escenario
Desde hace 3 años, estamos acompañando a un cliente start-up en el desarrollo de su plataforma, que ya ha pasado por 3 versiones y va por la cuarta (la estamos implementando). Los cambios entre versiones no sólo fueron de UX/UI, objetivos, e incluso audiencia, sino que también fuimos evolucionando, entre otras cosas, cómo manejamos los estados en la aplicación React en base a las necesidades y el crecimiento del equipo.
En principio, comenzamos manejando el estado usando Redux Toolkit. En esa época, Redux todavía era furor, y el uso de RTK para implementarlo solucionaba muchísimo la vida de cada Developer. Esto fue así por bastante tiempo, y eventualmente empezamos a usar Redux Toolkit Query para manejar los requests al back end.
Irónicamente, este último paso fue el principio del fin para Redux como nuestro manejador de estado predeterminado. Como RTK Query abstrae el manejo de las respuestas y los estados de las queries, quedaba poco por manejar a mano en el estado, y hacerlo con Redux resultaba algo molesto.
¿Cómo lo resolvimos?
Casi en simultáneo, comenzamos a utilizar Context API para algunos casos particulares en los que necesitábamos tener un estado particular en lugares específicos del DOM (más sobre esto próximamente). Esto hizo que empecemos a tomarle cariño a Context API, y a usarlo para manejar los nuevos estados (ya no tan globales).
La nueva versión 4 trajo un ajuste importante. En lugar de ser un cambio de diseño (y de target), también aprovechamos el momento para actualizar la tecnología. Dejamos atrás el proyecto de casi 3 años, e iniciamos a trabajar en un repo completamente nuevo. Esto nos permitió reconsiderar las viejas tecnologías que veníamos utilizando, y dio lugar a nuevas como Zustand, que apareció en la cancha. Aunque mantenemos Redux Toolkit Query para el manejo de requests al back end (y no lo reemplazamos para evitar tener que aprender muchas cosas nuevas de golpe), todo lo que es estado no local ahora lo maneja Zustand, y en las ocasiones que lo requieren, Context API.
¿La razón? Si bien Context API es mucho menos verboso que Redux (incluso con RTK), todavía no es tan simple como Zustand y tiene un problema que considerar. Si se cambia un valor del contexto, todo componente que está dentro del provider de dicho contexto va a ser re-renderizado. En algunos casos esto no es un problema, pero sí un limitante importante por tener en cuenta, por lo que decidimos agregar otra librería que resuelva esta desventaja.
De esta forma, datos que son particularmente estáticos o que cambian en el nivel más alto del DOM contenido por el contexto (lo que causaría un re-render de todas formas) son manejados por Context API; pero el resto (la mayoría) ahora usan Zustand. Esto nos permite escribir con muy poco código un estado bien estructurado, nos facilita más que antes la eliminación de prop drilling… y nos da un chiche nuevo para jugar.
Ahora les pregunto a ustedes: ¿Cuál fue su experiencia con los distintos métodos de manejo de estado en sus apps?
Maximizando la fiabilidad de tareas programadas en entornos de microservicios con ShedLock y Spring
Por Darío Aguiar, Technical Leader
Escenario
Para uno de nuestros clientes perteneciente a la industria de seguros era necesario ejecutar procesos fiables en un entorno de microservicios. Como requisito, estos procesos debían ejecutarse de manera asíncrona, fuera de horario operativo y serían responsables de actualizar el estado de solicitudes de clientes, ya sea de manera individual o masiva.
¿Cómo lo resolvimos?
Para los procesos batch en un entorno de microservicios incorporamos ShedLock (junto a Spring, el framework base de los servicios), lo que nos brindó una solución elegante y escalable para el problema de bloqueo entre dichos procesos. Esto nos permitió centrarnos en la lógica de negocio y delegamos en ShedLock la sincronización de los procesos, evitando ejecuciones indeseadas y problemas de integridad de datos.
Usar la integración de ShedLock con el framework de Spring nos brindó una solución completa y robusta para la gestión de tareas programadas y los bloqueos en aplicaciones distribuidas que se hayan desarrollado con Spring Boot. Spring proporciona un entorno de desarrollo flexible y escalable, mientras que ShedLock agrega la funcionalidad crucial de bloqueo distribuido, lo que resultó un sistema muy eficiente y confiable: 100% recomendado!
Creación de un template base inicial para desarrollar aplicaciones de React
Por Leonardo Galdames
Escenario
En nuestro equipo trabajamos en el desarrollo de aplicaciones web para clientes de diversas industrias. En un proyecto reciente, nos enfrentamos al desafío de crear múltiples aplicaciones React con componentes y estilos similares, pero con funcionalidades específicas para cada una. Esto implicaba un proceso de desarrollo repetitivo y lento, ya que debíamos configurar la base de cada aplicación de forma manual.
¿Qué es un template base para aplicaciones React?
Es una plantilla predefinida que contiene la estructura básica de una aplicación React, incluyendo componentes reutilizables, estilos predefinidos y configuraciones esenciales. Al utilizar un template base, quienes están en rol de Developers pueden ahorrar tiempo y esfuerzo al iniciar nuevos proyectos, ya que no necesitan configurar todo desde cero.
¿Cómo lo resolvimos?
Para abordar el desafío de crear múltiples aplicaciones React similares, decidimos desarrollar un template base para esa tecnología, y además una biblioteca de componentes y estilos usando Storybook. Este template base incluyó:
- Componentes reutilizables: componentes básicos como botones, formularios, tarjetas y tablas.
- Estilos predefinidos: una paleta de colores, tipografías y estilos globales.
- Configuraciones esenciales: configuración básica de herramientas como Webpack, Babel y Jest.
Conclusión
La creación de este template base nos permitió:
- Acelerar el desarrollo de nuevas aplicaciones, ya que al usar el template base, quienes estaban en el desarrollo podían iniciar nuevos proyectos de manera rápida y centrarse en las funcionalidades específicas de cada aplicación.
- Mantener la consistencia, porque todas las aplicaciones desarrolladas con el template base comparten una apariencia y experiencia de personas usuarias coherentes.
- Mejorar la calidad del código, ya que el template base define estándares de codificación y buenas prácticas, lo que mejora la calidad general del código de las aplicaciones.
Autenticación de dos factores (2FA) exprés a partir de una implementación de autenticación simple con JWT
Por Walter Alessandrini, Technical Leader
Escenario
Un importante cliente de terminales de trenes en Emiratos Árabes Unidos solicitó la inclusión de un segundo factor de autenticación a través de email. Para ese momento, contábamos con la implementación de autenticación/autorización por JWT y con poco tiempo para incorporar el nuevo requerimiento.
¿Cómo lo resolvimos?
En lugar de implementar una solución desde cero, decidimos implementar el segundo factor de autenticación apoyándonos en un almacén de datos en memoria compartida (Redis), en el que, una vez validados user y password, se genera una one-time password que se le comunica a la persona usuaria a través de un servicio de notificación y se guarda en Redis (encriptada) junto con su expiración asociada a dicha password. Una vez que la persona usuaria recibe el código OTP en su correo electrónico, lo ingresa a través de la UI de la aplicación y lo envía. Si el OTP enviado coincide con el que está guardado en Redis, se genera el JWT y se envía. Luego, el esquema de autenticación y autorización continúa de la misma manera en la que se había implementado con anterioridad.
