Microfrontend design

In the world of web development, there are always new technologies and approaches emerging that promise to revolutionize the way we build applications. In this article, I would like to introduce you to a relatively new architecture for creating web applications that has the potential to greatly improve the development process and help you overcome the common challenges faced by developers when creating modern web applications. By decomposing your application into smaller, self-contained units, you can improve code reuse, reduce complexity, and increase the speed at which you can deliver new features to users. Whether you are tired of working with monolithic frontend codebases that are difficult to maintain and scale, or you are looking for a way to improve the agility of your development process, microfrontends may be the solution you've been searching for.

What is microfrontend?

Let's start with the basics and explain what exactly microfrontends are and what makes them different. Microfrontends are software architecture pattern that involves decomposing a monolithic frontend application into multiple smaller, self-contained frontend applications that can be owned and developed by different teams. The goal of this pattern is to improve the scalability, maintainability, and flexibility of the frontend development process by allowing each team to work independently on their own microfrontend and integrate their changes into the larger system without affecting the work of other teams. Each microfrontend is responsible for a specific feature or part of the user interface and has its own codebase, build process, and deployment pipeline.

One of the main advantages of using microfrontends is that it allows teams to have free choice of technology when building their microfrontends. This means that each team can choose the tools, frameworks, and libraries that best fit their needs and preferences, without being constrained by the choices of other teams. This modular approach allows teams to work on different parts of the application in parallel, without affecting the rest of the codebase. Microfrontends are typically integrated into the main application using some form of frontend integration layers, such as an iframe or a web component. This layer is responsible for loading the individual microfrontend and composing them together to form the final user interface. They are particularly well-suited to large, complex applications that are maintained by multiple teams.

Alternative to NPM packages

Microfrontends are often compared to npm packages, mainly due to the fact that they turn out to be a substitute for them. The main difference between these approaches is the scope of the modularization. Npm packages are used to modularize code at a much smaller scale, typically encapsulating a specific utility or library. On the other hand, microfrontends are used to modularize the entire frontend application, dividing it into smaller parts. There are several key differences between npm packages and microfrontends, including deployment, integration, responsibility and collaboration.

Npm packages are typically deployed to a package registry and then installed in a project using a package manager like npm or yarn. Microfrontends, on the other hand, are deployed as standalone applications and integrated into the main application using an integration layer.

Regarding integration, npm packages are usually integrated into a project by importing their exports in the source code. Microfrontends are usually integrated using an iframe, a web component, or a similar technique.

When it comes to responsibility npm packages are designed to provide a specific, narrowly-defined piece of functionality, such as a library or utility. They are typically used within a single project to share code between different parts of the application. Microfrontends, are responsible for a larger portion of the application. They are used to modularize the application into independent elements.

In terms of collaboration npm packages are typically developed and maintained by a single team or individual. Microfrontends can be developed and maintained by multiple teams, allowing separation of concerns.

Microfrontends do not replace npm packages; each solution has its advantages and disadvantages, and the choice of the appropriate approach should be determined by analyzing the requirements for your web application. In general, npm packages are more suitable for smaller-scale code reuse, while microfrontends are better suited for large, complex applications that are maintained by multiple teams.

When to use microfrontends?

After the introduction to the idea and the advantages of microfrontend architecture, you may ask yourself whether microfrontends should be used in every application? When should I consider introducing them? There are several factors that can influence the decision to use microfrontends in your application. Here are a few potential scenarios where that architecture may be a good fit:

• Your application has a large, complex frontend codebase that is difficult to maintain and scale: By breaking the frontend codebase into smaller, self-contained components, it can be easier for teams to work independently and make changes without affecting the rest of the application.
• When many teams are working on the application frontend concurrently: By allowing each team to work on its own microfrontend, it can be easier to manage dependencies and avoid conflicts.
• The application needs to support multiple languages or frameworks: By building each microfrontend as a standalone component, it can be easier to use different languages and frameworks for different parts of the application.
• Your project needs to be highly modular and flexible: By allowing teams to develop and deploy microfrontends independently, it can be easier to add or remove features or functionality from the application without affecting the rest of the system.

Overall, the decision to use microfrontends will depend on the specific needs and goals of the application, as well as the resources and constraints of the development team. It is important to carefully consider the trade-offs and potential challenges of using this architecture before deciding to implement it in a project.

How we introduced microfrontend using web components into our projects

We recently faced a challenge  where we needed to maintain several independent web applications, but some of them needed to contain a common, identical operating and looking interface element. We needed to find a way to share this element across the different applications without duplicating the code. After considering our options, we decided that the best approach would be to use a microfrontends architecture. We chose this approach for several reasons. First, microfrontends allowed us to ensure the independence of each application. By dividing the interface element into its own microfrontend, we were able to give each team complete control over its own codebase and deployment pipeline. Second, microfrontends gave us the ability to make changes to the interface element quickly and easily. By promoting the microfrontend to its own codebase, we were able to give each team the ability to make changes to the interface element at any time, without needing to coordinate with other teams.

Overall, our decision to use a microfrontends architecture was driven by the need to ensure the independence of each application and the ability to promote changes by each team at any time. We believe that this approach will pay off in the long run.

After choosing the architecture, we moved on to the implementation. We knew that there are many ways and technologies in which microfrontends can be implemented, but due to the simplicity of implementation and the support of the Angular Elements library, we decided to add microfrontends into our project by using web components. To create them we started with making a simple Angular component and defining the custom element with the createCustomElement() function from the Angular Elements package This function takes the component class as an argument and returns a custom element definition. In the next step, our custom element needed to be registered in the browser, to do that we used customElements.define() function.

Then was the time to embed the custom element in our hosting application. Once our custom element was registered, we could use it in the main application just like any other HTML element. To set the communication process between the hosting application and the web component such as setting properties or listening for events we used standard Angular inputs and outputs. The last step was to deploy a bundled package with the web component from a separate URL so that it and all its logic could be downloaded by the hosting application

Encountered problems and lessons learned

Despite the advantages of using web components, the implementation process was not without its challenges. We encountered a number of problems along the way, some of which were quite unexpected. If you're interested in learning more about these challenges and how we overcame them, we encourage you to come to our upcoming tech meetup dedicated to the topic of Internet applications in hybrid "cloud-on-prem" solutions, hosted by Motorola Solutions.

At the meetup, we'll be sharing our experiences with implementing microfrontends using web components and discussing the problems we encountered along the way. We'll also be answering your questions and sharing our insights. In addition to microfrontends, we'll also be exploring the topic of server-sent events and multi-screen web applications. More information about the meetup can be found here.

So if you're interested in learning more about microfrontends and the challenges of implementing this software architecture, we hope to see you at the meetup. So don't miss out - register now and join us. We look forward to seeing you there!