#LemonCode 🍋 – Microfrontends II: Beneficios y Retos

Buy Me A Coffee

Beneficios

  • Construir en piezas pequeñas trae todas las ventajas de los componentes a nivel de aplicación: reducimos complejidad, funcionalidad y responsabilidad acotadas, tests sencillos, mejor mantenibilidad, menor acoplamiento, bases de código más ligeras, etc.
  • La funcionalidad se vuelve más escalable, es decir, levantar un nuevo microfrontend es más barato, o al revés, tirar un microfrontend a la basura es menos caro que cuando trabajamos con monolitos acoplados (Figura 2).
Figura 2. Funcionalidad escalable
Figura 2. Funcionalidad escalable
  • El punto anterior nos lleva de forma natural al siguiente: ahora las actualizaciones de código pueden ser incrementales, sin impactar al resto de microfrontends existentes. Por tanto reducimos el riesgo de deuda técnica (Figura 3).
Figura 3. Actualizaciones incrementales
Figura 3. Actualizaciones incrementales
  • Podremos tener repositorios, pipelines, despliegues, entornos y procesos independientes por cada microfrontend. Y ¿por qué no? equipos autónomos (Figura 4).
Figura 4. Equipos y procesos independientes
Figura 4. Equipos y procesos independientes

Read the complete article here.

Happy coding!

Greetings

El Bruno



¿Con ganas de ponerte al día?

En Lemoncode te ofrecemos formación online impartida por profesionales que se baten el cobre en consultoría:

#LemonCode 🍋 – Microfrontends I: Introducción

Buy Me A Coffee

Motivación

Si echamos la vista atrás en el desarrollo de aplicaciones web, front y back suelen evolucionar en paralelo hacia soluciones y arquitecturas más efectivas:

  • En su origen, una web app no era más que un gran monolito con toda la lógica de front y back empaquetada junta.
  • A medida que las aplicaciones se hacían más complejas, se pone de manifiesto la necesidad de separar front y back. Nacen las SPA (Single Page Aplications) que se comunican a través de APIs.
  • Back inicia su andadura hacia los microservicios: una arquitectura distribuida, modular y escalable que trae numerosas ventajas.
  • En front también cala esta filosofía del ‘divide y vencerás’. La componentización aparece de forma natural con todos los nuevos frameworks de desarrollo de aplicaciones. Gracias a los componentes, rompemos nuestra UI en pequeños trocitos que permiten el reuso de elementos, reducir la complejidad, aplicar el principio de responsabilidad única, favorecer el testeo, etc.

Sin embargo, los componentes en front no son del todo equiparables a los microservicios en back. A pesar de modularizar nuestra UI, los componentes no solemos concebirlos como entidades 100% independientes, sino como partes de un todo. Tanto es así que en el último paso previo al despliegue … ¿qué hacemos? … ejecutamos un bundler que agrega toda la aplicación en ¡un gran monolito!**

Si bien en tiempo de desarrollo hemos aplicado principios modulares, en tiempo de ejecución nos quedaría una foto como la siguiente (Figura 1):

Figura 1.  Front  (monolito) vs  back  (arquitectura distribuida)
Figura 1. Front (monolito) vs back (arquitectura distribuida)

¿Por qué no dar un paso más y emular la arquitectura distribuida que ya se practica en back-end?

Read the complete article here

Happy coding!

Greetings

El Bruno



¿Con ganas de ponerte al día?

En Lemoncode te ofrecemos formación online impartida por profesionales que se baten el cobre en consultoría: