Introduction to Micro Frontend Architecture

In the recent time during the transformation journey, the trend is to build powerful rich and powerful Single Page Applications backed up by Microservices architecture. But, if we think of a holistic view of the end-to-end customer journey, backend infrastructure, service support, DevOps, reusability, loosely coupled components then Micro Frontends architecture can be a vital part in conjunction with Microservices architecture.

Before we discuss about Micro Frontends, let’s understand what Frontend Monolithic is. Over the years, frontend layers are developed by various teams which resulted in large User Interface layers which are very difficult to maintain. From the product team’s mindset perspective, it’s always ideal if the same team owns Frontend and Backend which helps in overall better support and maintainability. But, if we think about monolithic Frontend then a single team can only own a portion of functionalities otherwise, they can be overly occupied with work.

Below picture shows the journey from Monolithic to Fronted and Microservices architecture:

Micro Frontends can be a solution to solve the challenges mentioned above. The whole idea behind Micro Frontends is to think about a website or web app as a composition of features that are owned by independent teams. Each team has a distinct area of business or mission it cares about and specializes in. A team is cross-functional and develops its features end-to-end, from the database to the user interface.

Micro Frontend became more popular with the introduction of languages like Angular, React, Salesforce Lightning Web Components which focuses on modular development. A single component is responsible for frontend and backend with its own packaging that should be reusable and independently deployable which provides great flexibility and improves time to market.

Micro Frontend brings an option to break the complex monolithic applications into a logical grouping of functionalities using Microservices architecture Service Mesh. But, teams need to consider dependencies, ownership, and DevOps aspects with a long-term vision otherwise it may also be hard to maintain the “n” number of components.