引入微服务令我们受益匪浅，使用微服务，团队可以扩展那些独立部署及维护的服务的交付。遗憾的是，我们也看到许多团队创建了单体前端——一个建立在后端服务之上的大而混乱的浏览器应用程序——这在很大程度上抵消了微服务带来的好处。自从问世以来， 微前端 持续变得流行。我们已经看到，许多团队采用这种架构的某种形式，来管理多开发人员和多团队的复杂性，以提供相同的用户体验。在去年的六月份，这个技术的发起人之一，发表了一篇介绍性的文章，可以起到微前端参考文献的作用。它展示了这种设计是如何通过各种Web编程机制实现的，以及使用React.js构建了一个示例应用程序。我们有理由相信，随着大型组织尝试在跨多团队中分解UI开发，这种风格将越来越流行。
引入微服务令我们受益匪浅，使用微服务，团队可以扩展那些独立部署及维护的服务的交付。遗憾的是，我们也看到许多团队创建了单体前端——一个建立在后端服务之上的大而混乱的浏览器应用程序——这在很大程度上抵消了微服务带来的好处。自从问世以来，微前端持续变得流行。我们已经看到，许多团队采用这种架构的某种形式，来管理多开发人员和多团队的复杂性，以提供相同的用户体验。在今年的六月份，这个技术的发起人之一，发表了一篇介绍性的文章，可以起到微前端参考文献的作用。它展示了这种设计是如何通过各种Web编程机制实现的，以及使用React.js构建了一个示例应用程序。我们有理由相信，随着大型组织尝试在跨多团队中分解UI开发，这种风格将越来越流行。
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.
