Infoxicator.com

La Historia de Micro-Frontends

Publicado

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.


Artículos Recientes

Traduciendo Mi Blog Con Next.js

Next.js ha facilitado la internacionalización (i18n) de sitios web con una de las nuevas funciones avanzadas en la versión 10

Reglas de los Micro-Frontends

Esta es una lista con las mejores prácticas para diseñar aplicaciones que siguen el patrón Micro-frontend

Dark Mode No es Suficiente! Esta es una alternativa…

En estos días, la mayoría de los sitios web tienen la opción de alternar el modo oscuro, pero ¿y si quisiera más?