El concepto de micro frontend engloba un conjunto de técnicas, estrategias y recetas para desarrollar aplicaciones web complejas con un conjunto de equipos de desarrollo que pueden trabajar de forma independiente. En cierto modo es la extensión de la arquitectura de microservicios al front-end.
Cada equipo se encarga de una o más funcionalidades y las programa completamente (la base de datos, el backend, el frontend,…). Luego estas funcionalidades se componen para construir la aplicación final. La idea es que las funcionalidades de cada equipo tengan pocas dependencias con las de los otros equipos para que esta composición sea lo más fácil posible. Además conviene seguir convenciones preestablecidas y las mismas buenas prácticas en cada equipo para minimizar las sorpresas.
La principal novedad de los micro front-ends es que los equipos de desarrollo no se separan por tecnología (el clásico ejemplo de equipos backend y equipos frontend) sino que són equipos transversales con todos los perfiles necesarios para desarrollar una funcionalidad completa. La imagen que encabeza este post esquematiza esta estructura. La siguiente imagen (sacada de la página sobre micro frontends por excelencia) lo muestra con un ejemplo basado en una tienda que vende tractores. Un equipo (el rojo) se encarga de gestionar la visualización de los detalles de los modelos de tractores, el equipo azul se encarga de todo lo relacionado con el proceso de compra mientras que el verde se focaliza en el componente encargado de sugerir productos relacionados. En este contexto, los “t-shaped developers” pueden jugar también un rol importante al facilitar la comunicación entre los diferentes perfiles del equipo.
El término Micro Frontends apareció por primera vez en el ThoughtWorks Technology Radar en 2016, aunque es una evolución de conceptos y arquitecturas previas como los sistemas autocontenidos o la integración de frontends para sistemas verticales. Es muy importante tener claro que no son una solución a un problema tecnológico sino una solución a un problem organizativo que pretende faclitar el desarrollo de aplicacione complejas, sobretodo a nivel de coordinación de los diferents equipos ofreciéndoles mayor autonomíy focalizando la distribución del trabajo en una distribución funcional y no tecnológica.
Evidentemente nada es gratis. Usar este estilo arquitectónica obliga a definir los puntos de integración y las interfaces entre los diferentes equipos. Este esfuerzo sólo tiene sentido en desarrollos y equipos de un cierto tamaño. Si queréis profundizar en los patrones y tecnologías concretas (en el campo de las aplicaciones web) que os pueden ayudar en esta coordinación de equipos y la integración de los componentes en el front-end resultante, os recomiendo tanto esta entrevista a Michael Geers como el libro que él mismo ha escrito:
Últimos comentarios