Developing the frontend of your page or app can be hard work, especially with such considerations as team size and how complex the finished product might be. This article will look at an alternative architecture framework known as “Micro Frontends” and why this can be the right choice when considering such issues.
When creating a web app or single-page application (SPA), unless the project is very small, there are likely to be multiple developers working on same single and indivisible block of code. This is because many frontend frameworks employ an architectural style known as monolithic architecture, where all of the functionality is contained in the same place.
Learn more: Monolithic vs microservices—which is better
This can lead to communication issues between teams, creating problems in the code and so ultimately making for poor DevOps practice. This in turn can slow down important processes like testing and deployment and so lead to missed deadlines.
One recent solution to this issue is to deploy micro frontends. Here the frontend monolith architecture is separated and broken down into easier-to-handle components. Each component has its own specific function and is not necessarily dependent on any other component. This creates a more versatile, flexible frontend framework where teams can concentrate on their own piece of the whole and so lessen the chances for errors.
Whether adopting this approach is the correct choice for a business will depend on factors pertaining to the size of the business itself, the resources available to it, and the overall planned complexity of the project.
What is micro frontend architecture?
As noted, this is a component-based architecture where an individual micro frontend application is responsible for its own function. These come together and form the entire client-side user interface: each frontend is a chunk of the entire front page, but unlike in monolith architecture, does not constitute the whole.
This method of frontend development gained prominence in 2020 when Zack Jackson described it in his 2020 paper Module Federation. Here Jackson detailed how isolated or remote components could be developed independently and deployed without the need for an existing monolith to locate such components in.
Companies took note and began adopting micro frontends over monolithic frontends. Two notable companies that use micro frontends are IKEA and Spotify.
Developers working on the different parts of a monolith have a lot of plates to keep spinning, as the applications they work with feature components and applications that are all interdependent and contained on one web server. Even if they have their own separate DevOps plans and teams to concentrate on them, the fact they are all housed in the same monolith causes issues arising from interdependance and cross-cutting concerns. Other teams working in such a situation can sometimes accidentally work against colleagues or create problems in the code or database as a result.
However, when concentrating on a single micro frontend component, teams can work on and deploy each one independently during the development process, resulting in the benefits of an autonomous team.
The various APIs or functions are assembled together to create the front page. The front page is therefore something that emerges from a collection of separate features, with no accompanying issues of interdependence or teams working across multiple parts of the same whole and potentially making mistakes with implementation details.
Each developer team, if given their own concrete set of KPIs and web component spec for the custom elements they are working on, can concentrate exclusively on their own portion of the whole client-side interface, with no cause for concern over team conflicts. As we’ll see, this also has attendant consequences in terms of deployment, scaling, testing, and modularity.
Benefits of micro frontend architecture
Library development
Different teams who have tested and deployed the components that they are responsible for can reuse the code and so reintroduce the component into other projects. This allows for the creation of that company’s own library ecosystem of web components and web applications.
Flexibility and variation
Developers can choose which kind of frontend framework, such as React or Vue, or programming language they would like to employ in the creation of the frontend they are responsible for. This allows for maximum working preference and comfort for developers, leading to insightful and dynamic thinking, as the project doesn’t then have to adhere to the same framework or programming language.
Speed
If the project has enough resources to employ enough frontend teams, then the app can be created quickly with teams working on their own micro frontend components, goals, and deadlines and being responsible for their own testing and deployment.
Scalability
If the app or page is complex, it will need scaling over time. Again, if the resources of the project allow for multiple teams, then these teams can work on and grow their own frontend portion with incremental upgrades, leading to the app scaling at manageable pace over time with multiple teams responsible for their own designated micro frontend implementations.
Developer experience
It is much easier to learn the code required for a single microservice than for an entire monolith. Also, developers can choose the language they are most familiar and comfortable with using when working on their component. This allows businesses access to a greater pool of potential staff, potentially working on multiple applications, as they needn’t rely only on the most experienced members. This also has corresponding advantages for budget considerations.
Independent deployment and testing
Teams deploy only the component that they have developed. Because the frontends are independent, this means that deployment and other changes can affect only that specific microservice, and cannot cause changes to the whole. This also means that teams are responsible only for the testing and monitoring of one aspect of the whole, so avoiding the need for the entire project to be monitored and tested at the same time.
Drawbacks of micro frontend architecture
Resources
For the above advantages of micro frontend architecture to be realized, the project must have access to multiple teams. If a business does not have the sufficient size or resources for micro frontend projects, then microservices could actually prove to be more cumbersome and demanding than simply using a monolith.
One team would be responsible for the creation, testing, and deployment of multiple modules, possibly across several languages, rather than just attending to one code base. This is not an efficient use of time. If a separate team is available, then microservices can be considered.
Complexity
There is a danger of scope creep when using micro frontend architecture. It is possible for developers to overpopulate their project with too many components as time goes on, causing multiple testing and deployment-phase issues to appear across several teams.
This requires a detailed and complex planning stage to decide the exact number and extent of components to be employed. Likewise, each developer team will require an exact set of KPIs to follow. All this requires more management, and so, resources.
Payload
The microservices employed can entail the need to duplicate common dependencies. This means, for examples that if a micro frontend requires a specific program to be installed in order for it to function, then client-side users are also required to download a corresponding copy. This is true for each component, meaning there might be multiple download requirements to ensure complete functionality and browser support.
This is an issue, because many user contexts rely on infrastructure that is poorer in performance than that used by the developers, so extra data demands are a disadvantage – users will not return to web apps that have poor page performance. Using components that have native browser support can help remedy this effect, as this reduces reliance on downloads.
How best to use micro frontend architecture
Modularity is central
Modularity is a key benefit of using micro frontends, and as such, this feature must be included in, and be central to, the planning stage of any project that plans on using them. If this example of best practice is not present, then it is difficult to gain the full benefits of microservices over frontend monoliths. This is because it is necessary that unique teams work on the independent components. As such, they can be tested and deployed at different times.
This gives excellent flexibility as to the rolling out and execution of a completed app, and deployment times and the resources that should be allocated can be planned in advance. This is extraordinarily useful in keeping a project on track and on time. If the plan, however, is for the entire application to be deployed at the same time, then a frontend monolith might as well be used.
Planning is key
The correct number of frontends for the project as a whole must be meticulously planned. Careful planning involves a needs analysis in terms of what is necessary to deliver the desired functions of the app. Without such an analysis, there is a danger that too many or too few microservices may be deployed.
As noted, scope creep can be a feature of projects that use microservices on the client side. This can lead to too great a number of frontend components being included. This should be avoided as multiple components can become interconnected, resulting in the micro frontend architecture more functionally resembling monolithic architecture.
In addition, a planning and analysis page will ensure that there are not too few microservices. When the number of independent components employed is too small, then is it is difficult for an app to deliver the functionality the developers have been asked to provide.
An e-commerce page, for example, typically has cross-team API interactions dealing with log-ins, payment checkouts, customer communications, and the means to log user data for subsequent customer recommendations to ensure a good retention rate. All of these features are key to the success of the project. It is better to employ one component for each main feature, than to use several for each feature. Aligning the aims of independently deliverable frontend applications with key processes for the product or service will also ensure that the frontends employed are correct in number.
In summary
Micro frontend architectures are not suitable for small companies that can only employ small teams. The time commitments arising from the amount of work required for component development makes the microservice approach too much of an investment for the available resources. In this particular business context, monolithic architecture for the frontend is more appropriate.
As mentioned, IKEA and Spotify both use micro frontend architectures. So do Starbucks. These companies have a lot of resources available, and so can roll out microservice frontends easily. This does not mean, however, that this style of architecture is solely for huge corporations. Any business context that allows for the allocation of autonomous teams to the necessary component elements will be able to reap the benefits and rewards of the microservices approach.
The larger the project, the more likely a micro frontend application will be justified due to the issues aligned with scaling complex apps and the necessity of avoiding interdependent components. Payload issues can be reduced with solutions that favor native browser features.
