Temos visto significativos benefícios de se introduzir microsserviços, que permitem aos times escalar a entrega de serviços mantidos e implantados independentemente. Infelizmente, também vemos muitos times criarem um monólito de frontend – uma grande e confusa aplicação de navegador que fica em cima de serviços de backend –, neutralizando fortemente os benefícios dos microsserviços. Os micro frontends continuam a ganhar popularidade desde que foram introduzidos. Temos visto muitos times adotarem alguma forma dessa arquitetura como uma maneira de gerenciar a complexidade de múltiplas pessoas desenvolvedoras e times contribuindo para a mesma experiência de usuário. Em junho deste ano, um dos criadores dessa técnica publicou um artigo introdutório, que serve como referência para micro frontends. Ele mostra como esse estilo pode ser implementado usando vários mecanismos de programação web e constrói um exemplo de aplicação usando React.js. Estamos confiantes de que esse estilo vai crescer em popularidade à medida que grandes organizações tentam dividir o desenvolvimento de UI entre múltiplos times.
Temos visto significativos benefícios de se introduzir microsserviços, que permitiram que times escalassem a entrega de serviços mantidos e implantados independentemente. Infelizmente, também vimos muitos times criarem um monólito de front-end – uma grande aplicação de navegador confusa que fica em cima de serviços de back-end –, neutralizando fortemente os benefícios dos microsserviços. Os micro-frontends continuaram a ganhar popularidade desde que foram introduzidos. Temos visto muitos times adotarem alguma forma dessa arquitetura como uma maneira de gerenciar a complexidade de múltiplos desenvolvedores e times contribuindo para a mesma experiência do usuário. Em junho deste ano, um dos criadores dessa técnica publicou um artigo introdutório que serve como uma referência para micro-frontends. Ele mostra como esse estilo pode ser implementado usando-se vários mecanismos de programação web e constrói uma aplicação de exemplo usando o React.js. Estamos confiantes de que este estilo vai crescer em popularidade à medida que grandes organizações tentam dividir o desenvolvimento UI entre múltiplos times.
Temos visto benefícios significativos com a introdução de microsserviços, que têm permitido aos times escalar a entrega de serviços implantados e mantidos independentemente. Infelizmente, também temos visto muitos times criarem um monólito de frontend — uma aplicação para navegador grande e confusa sobre seus serviços de backend — neutralizando os benefícios dos microsserviços. Desde que apresentamos os micro frontends como uma técnica para resolver essa questão, tivemos experiências positivas com a abordagem e encontramos vários padrões para usar os micro frontends, mesmo conforme mais e mais códigos migram do servidor para o navegador web. Até agora, contudo, os componentes web têm sido confusos neste campo.
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.
