Algo Que Pasa Seguido

Son las 5:30 pm un viernes y te toca implementar una arreglo muy importante a tu aplicación; Inicias el deplego y esperas a que se ejecuten los 50 mil unit y integration test. Justo antes de que finalicen los test, recibes un mensaje de otro equipo a decirte que la actualización que se aplicó la semana pasada para habilitar el “Dark Mode” aún no se ha sido aprobada y, debido a que está incluida con tus cambios, te hacen parar el despliego. A este punto, te dan ganas de llorar y cambiar de carrera 🤦‍♂️

Te ha pasado algo parecido? si has estado en esta situación entonces te vendría bien un “cambio de mentalidad”.

Descubre arquitectura de nueva generación: Microservices para el frontend!

Pero Primero, Un Poco De Historia…

No hace mucho, nuestras aplicaciones web se construían como un enorme “monolito”; backend y frontend juntos; pero a medida que las aplicaciones comenzaron a crecer, decidimos “dividir” el backend y el frontend y vimos el surgimiento de las SPA (single page applications) que se comunican a través de APIs. Los equipos del backend tuvieron su evolución y también “dividieron” sus aplicaciones en microservicios. Mientras tanto en el fronend, el concepto de “components” fue introducido por librerias populares como React que proporcionaban composición y reutilización a nuestro código. Ahora bien, ¿por qué el frontend se detuvo allí? aquí es donde aparece el nuevo concepto de Micro-frontends como el siguiente paso en la evolución del desarrollo web.

Que Son Micro-frontends?

La arquitectura Micro-frontend es un nuevo paradigma que nos permite dividir el “monolito del frontend” en experiencias de usuario pequeñas, reutilizables e independientes.

Estas experiencias tienen sus propios repositorios, su propio CI/CD y se pueden desplegar y testear de forma independiente.

Beneficios

Desplegar De Forma Independentiente 🚀

• Reducir Riesgo: solo se está desplegando lo que ha cambiado en lugar de la aplicación completa. “Si no está roto, no lo arregles”
• Arreglos rápido en Producción: evitar dependencias en otros equipos o código nos permite desplegar arreglos importantes más rápido.
• Testing Simplificado: ejecutar tests para las interfaces individuales con límites definidos y garantizando su funcionalidad siguiendo el enfoque de responsabilidad única.

Equipos Independentes 👨‍🏫

• Propiedad Completa : La división vertical se puede aplicar a la estructura del equipo y ser dueños de funciones completas incluyendo el frontend y backend.
• Prevenir Dependencias: La autonomía del equipo ayuda a reducir la necesidad de coordinación y ayuda a evitar interferencias / bloqueos.
• Velocidad de Desarrollo: Mayor velocidad y autonomía para desarrollar las aplicaciones rápidamente.

Código Separado ✍️

• Mejor Experiencia Para el Desarrollador: Mejoras en productividad y concentración.
• Reducción en Tamaño del Proyecto: Ayuda a los desarrolladores a comprender mejor el código y evita verse abrumados por un enorme proyecto.
• Evita Aclopamiento Accidental: Los desarrolladores solo interactúan con partes específicas del código cuando desarrollan nuevas funciones y debido a que existen límites establecidos, detiene la necesidad de conectar componentes que no deberían conectarse entre sí.

Reusabilidad 🗃

• Aplicaciones Encapsuladas: Las funciones creadas como experiencias de usuario independientes se pueden reutilizar fácilmente en toda la aplicación.
• Composición: similar a la reutilización de componentes lograda por composición, este enfoque también se puede aplicar a Micro-frontends.
• Reuso Por Parte de Otras Aplicaciones: Debido a que los Micro-Frontends tienen su propio CI/CD, pueden implementarse en diferentes aplicaciones e incluso compartirse como soluciones “plug and play” que contienen toda la lógica y la presentación de la interfaz de usuario necesaria para cumplir con múltiples casos de uso.

Desventajas 😞

• Eres el único desarrollador en el equipo?
• Haces parte de un equipo pequeño?
• Tu aplicación es pequeña?

Es posible que la arquitectura de Micro-frontends no sea una buena opción ya que es más adecuada para aplicaciones medianas y grandes con varios equipos que necesitan trabajar de forma independiente.

Al igual que con los microservicios, con Micro-frontends, hay una mayor cantidad de partes móviles que deben administrarse y configurarse aumentando la complejidad general de la aplicación. Sin embargo, estos problemas no son un producto directo de este patrón, sino un efecto secundario que viene con aplicaciones a gran escala y cuando se opera con aplicaciones grandes y varios equipos. Es posible que también se requiera algo de capacitación y nuevas herramientas para ayudar a orquestar todas las piezas y agruparlas.

Conclusión

A medida que sus aplicaciones comiencen a escalar, y que se empicen a agregar más desarrolladores al proyecto y se creen nuevos equipos, podría ser el momento adecuado para romper el “monolito” y brindarles a sus equipos la autonomía que necesitan para entregar aplicaciones más rápido a sus usuarios.