Hemos visto beneficios significativos al utilizar microservicios, que han permitido a los equipos escalar la entrega de servicios desplegados y mantenidos de manera independiente. Desafortunadamente, también hemos visto a equipos crear frontends monolíticos (aplicaciones web grandes y complejas sobre servicios del backend) que neutralizan en gran parte los beneficios de los microservicios. Los micro frontends continúan ganando popularidad desde que se introdujeron por primera vez. Hemos visto a muchos equipos adoptar de una u otra forma esta arquitectura para manejar la complejidad de múltiples personas desarrolladoras y equipos contribuyendo en la misma experiencia de usuario. En junio del año pasado, uno de los autores de esta técnica publicó un artículo introductorio que sirve de referencia para los micro frontends. Este artículo muestra cómo se puede implementar este estilo utilizando varios mecanismos de programación web e indica un ejemplo usando React.js. Confiamos en que este estilo crecerá en popularidad a medida que las organizaciones dividan
Hemos visto beneficios significativos al utilizar microservicios, estos han permitido a los equipos escalar la entrega de servicios desplegados y mantenidos de manera independiente. Desafortunadamente, hemos visto a equipos creando monolitos en el front-end — una gran aplicación web y enredada sobre servicios back-end — neutralizando en gran parte los beneficios de los microservicios. Los micro frontends continúan ganando popularidad desde que se presentaron por primera vez. Hemos visto a muchos equipos adoptar de alguna manera esta arquitectura para manejar la complejidad de múltiples desarrolladoras/es y equipos contribuyendo en la misma experiencia de usuario. En junio de este año, uno de los autores de esta técnica, publicó un artículo que sirve de referencia como un introductorio a micro frontends. Este muestra cómo se puede implementar este estilo utilizando varios mecanismos de programación web así como la construcción de una aplicación React.js. Estamos seguras/os en que éste estilo crecerá en popularidad a medida que las organizaciones descompongan el desarrollo UI en varios equipos.
We've seen significant benefits from introducing microservices, which have allowed teams to scale the delivery of independently deployed and maintained services. Unfortunately, we've also seen many teams create a frontend monolith — a large, entangled browser application that sits on top of the backend services — largely neutralizing the benefits of microservices. Since we first described micro frontends as a technique to address this issue, we've had almost universally positive experiences with the approach and have found a number of patterns to use micro frontends even as more and more code shifts from the server to the web browser. So far, web components have been elusive in this field, though.
We've seen significant benefits from introducing microservices architectures, which have allowed teams to scale the delivery of independently deployed and maintained services. Unfortunately, we've also seen many teams create front-end monoliths — a single, large and sprawling browser application — on top of their back-end services. Our preferred (and proven) approach is to split the browser-based code into micro frontends. In this approach, the web application is broken down into its features, and each feature is owned, frontend to backend, by a different team. This ensures that every feature is developed, tested and deployed independently from other features. Multiple techniques exist to recombine the features — sometimes as pages, sometimes as components — into a cohesive user experience.
We've seen significant benefits from introducing microservices architectures, which have allowed teams to scale the delivery of independently deployed and maintained services. Unfortunately, we've also seen many teams create front-end monoliths — a single, large and sprawling browser application — on top of their back-end services. Our preferred (and proven) approach is to split the browser-based code into micro frontends. In this approach, the web application is broken down into its features, and each feature is owned, frontend to backend, by a different team. This ensures that every feature is developed, tested and deployed independently from other features. Multiple techniques exist to recombine the features — sometimes as pages, sometimes as components — into a cohesive user experience.
We've seen significant benefit from introducing microservice architectures, which have allowed teams to scale delivery of independently deployed and maintained services. However, teams have often struggled to avoid the creation of front-end monoliths—large and sprawling browser applications that are as difficult to maintain and evolve as the monolithic server-side applications we've abandoned. We're seeing an approach emerge that our teams call micro frontends. In this approach, a web application is broken up by its pages and features, with each feature being owned end-to-end by a single team. Multiple techniques exist to bring the application features—some old and some new—together as a cohesive user experience, but the goal remains to allow each feature to be developed, tested and deployed independently from others. The BFF - backend for frontends approach works well here, with each team developing a BFF to support its set of application features.
We've seen significant benefit from introducing microservice architectures, which have allowed teams to scale delivery of independently deployed and maintained services. However, teams have often struggled to avoid the creation of front-end monoliths—large and sprawling browser applications that are as difficult to maintain and evolve as the monolithic server-side applications we've abandoned. We're seeing an approach emerge that our teams call micro frontends. In this approach, a web application is broken up by its pages and features, with each feature being owned end-to-end by a single team. Multiple techniques exist to bring the application features—some old and some new—together as a cohesive user experience, but the goal remains to allow each feature to be developed, tested and deployed independently from others. The BFF - backend for frontends approach works well here, with each team developing a BFF to support its set of application features.
