Micro Frontend

What is Micro Frontend?

Micro Frontend is an architecture in which the frontend of an application is decomposed into individual, loosely coupled "micro apps". This allows the frontend team the same flexibility and speed that microservices provide to the backend team. Each micro app can be built, tested, and deployed independently.

In the context of micro frontends, we have a host application and remote applications. The host app is the main application that provides the overall structure or functionality of the application, including navigation, authentication, global state management, and more. The host module is responsible for loading and integrating other micro frontends, which are referred to as "remotes".

A "remote" micro frontend is a self-contained module that provides a specific set of functionality or user interface components. Each remote is developed and deployed independently of the host and can be updated and scaled separately. When a remote is loaded into the host, it is rendered in a dedicated section of the user interface, referred to as a "slot". The host module can communicate with the remote modules through APIs or events to exchange data and trigger actions.

Each micro frontend can be managed by a different team and may be implemented using its own framework, such as Vue.js, React.js, and Angular. Each work team has the freedom to adopt the technology stack of its choice, without having to coordinate with other teams. Each frontend micro application function is handled as an independent service, which helps to avoid bottlenecks in the database.

There are different techniques for implementing micro frontends depending on the specific requirements and technologies involved:

Server-side composition:

With server-side composition, the different micro frontends are rendered on the server and then assembled into a single HTML page, which is sent to the client. This approach requires a server-side framework that can handle the composition and routing of the different micro frontends.

Client-side composition:

With client-side composition, the different micro frontends are loaded separately by the client and then assembled into a single page using JavaScript. This approach requires a client-side framework that can handle the composition and routing of the different micro frontends.

Iframe integration:

With Iframe integration, each micro frontend is developed and deployed independently, and then loaded into a separate iframe on the page. The parent page can then communicate with each micro frontend using JavaScript, allowing it to interact with the user and exchange data with the other microservices. However, Iframe integration may introduce some challenges such as affecting the performance of the page, particularly if there are many iframes loading simultaneously, and may introduce security vulnerabilities, such as cross-site scripting attacks. Also, it may affect the SEO of the site.

Web Components:

One of the main challenges with using Web Components in micro frontends is managing the communication and coordination between the different components. This requires a well-defined interface and communication protocol, as well as careful planning and coordination between the different teams working on each component. Overall, Web Components offer a powerful way to implement micro frontends, enabling better modularity, maintainability, and reusability of the frontend codebase. However, it is important to carefully plan and coordinate the development and deployment of the different components to ensure that they work together effectively and efficiently.

Why Micro Frontend?

Micro frontends offer several benefits over traditional monolithic frontend architectures. Here are some of the main reasons why micro frontends are gaining in popularity:

Scalability:

Micro frontends can be scaled up or down independently, depending on the traffic and usage patterns of each microservice. This enables better resource utilization and cost savings.

Flexibility:

With micro frontends, each team can work on their own microservice independently, using the technology stack they are most comfortable with. This enables faster development and deployment of new features and bug fixes, without having to coordinate with other teams.

Modularity:

Micro frontends enable a modular architecture, where each microservice can be developed, tested, deployed, and maintained independently. This can reduce development time and increase consistency across different projects.

Reusability:

Each micro frontend can be reused across different applications and contexts, reducing development time and increasing consistency across different projects.

Maintainability:

Since each microservice is responsible for a specific part of the user interface, it is easier to maintain and update the codebase. Changes to one microservice do not affect the others, reducing the risk of introducing bugs or breaking changes.

Innovation:

Micro frontends enable faster innovation by allowing teams to experiment with new technologies or approaches without impacting the rest of the application.

The following image shows the difference between monolith, front & back, and microservices:

The Monolith has a single team to create and maintain a complete application, sharing databases, backend and frontend.

The Front & Back divides the monolithic application into two, also dividing the work team to own its monolithic backend or front end.

With Microservices, the backend architecture evolved to a more scalable architecture, as each microservice belongs to a different work team.

Disadvantages of monolithic applications:

• Too large and complex for anyoneteam to fully understand and maintain.
• Difficult to scale and deploy independently.
• Changes and updates to one part of the application can affect other parts, leading to potential bugs and errors.
• Limited flexibility in terms of technology choice and development processes.
• Can become a bottleneck for innovation and new feature development.

Micro frontends offer a solution to these challenges, enabling more flexibility, scalability, and modularity in the frontend architecture. However, micro frontends also come with their own set of challenges, such as increased complexity in managing communication and coordination between different microservices, and potential performance issues with client-side composition and Iframe integration. It is important to carefully evaluate the specific requirements and challenges of each project before deciding whether to adopt a micro frontend architecture.

State Management in Microfront

State management is a critical concern when working with micro frontends because each micro frontend may have its own internal state that needs to be synchronized with the rest of the application. There are several approaches to state management in micro frontends, including:

Centralized state management: This approach involves using a central state management system to handle the state of the entire application. Each micro frontend can read from and write to this central state store as needed. Examples of centralized state management systems include Redux and MobX.

Decentralized state management: In this approach, each micro frontend manages its own state independently and communicates with other micro frontends using events or other messaging mechanisms. This approach can be more flexible than centralized state management, but it requires careful coordination between micro frontends to ensure that they are working with consistent data.

Hybrid approach: This approach combines elements of both centralized and decentralized state management. For example, a central state store might be used to manage global application state, while each micro frontend manages its own local state. The micro frontends can communicate with the central store to update or retrieve global state as needed.

The choice of state management approach ultimately depends on the specific requirements of your application and the trade-offs you are willing to make in terms of complexity, flexibility, and performance.