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)
¿Por qué no dar un paso más y emular la arquitectura distribuida que ya se practica en back-end?
**Nota: Es cierto que los bundles pueden ser troceados con el objeto de reducir tiempos de carga iniciales. Técnicas como el code splitting de webpack permiten generar sub-bundles. Pero esta herramienta, aunque puede resultar muy útil en el contexto de microfrontends, no representa por si misma una solución completa.
Microfrontend: Qué es
El término microfrontend comienza a sonar a finales de 2016. Y como toda nueva buzzword evoluciona por las fases típicas:
En el sitio Technology Radar de ThoughtWorks se recogen estas distintas fases para microfrontend, desde la fase de hype como concepto teórico que hace bastante ruido, pasando por evaluaciones y pruebas piloto para verificar su viabilidad, hasta la fase final de adopción, ya en 2019, cuando hay una fuerte voluntad por parte de la industria y la comunidad en adoptar definitivamente esta técnica.
Pero entonces, ¿qué es?
La palabra microfrontend designa un estilo o arquitectura, es decir, una forma de construir aplicaciones en front-end, donde dividiremos la funcionalidad en piezas más pequeñas e independientes
Bajo esta arquitectura, generaremos pequeñas sub-aplicaciones independientes (microfrontends) centradas en una funcionalidad concreta, que serán consumidas finalmente por una o múltiples aplicaciones mayores. Los objetivos de esta técnica son, fundamentalmente:
Acabar con los monolitos en front.
Traer los beneficios de un sistema modular.
Funcionalidad escalable.
Permitir flujos y equipos de desarrollo totalmente autónomos.
Hay múltiples aproximaciones e implementaciones posibles para conseguir los objetivos anteriormente vistos, por lo tanto es importante aclarar cierta confusión que todavía hay alrededor de este término:
NO ES ninguna tecnología en concreto.
NO ES un framework**.
NO ES un estándar.
Cada organización, siguiendo sus necesidades, ha explorado la forma de generar microfrontends con diversas tecnologías. Se siguen probando diferentes aproximaciones hoy día y a fecha de este artículo, no podemos decir que haya un caballo ganador que decante claramente la balanza.
Esta por ver si el futuro de los microfrontends será un estándar oficial o tecnología de facto, o por el contrario seguirá siendo una técnica con múltiples soluciones posibles.
**Nota: Existen 3rd parties orientados a generar microfrontends, como por ejemplo Single-SPA. Son una colección de utilidades y procedimientos ‘curados’ que ayudan a tal fin, pero no tiene porque ser la única forma ni la mejor de construir microfrontends.
Continuará en Microfrontends II: Beneficios y Retos