Devices come and go. Technology evolves. But browsers have been a mainstay since the internet took its first commercial steps in the early 1990s. From Netscape to Firefox, they’ve been a constant in every user’s toolkit, and they’ve never stopped evolving. The latest big step in that evolution is the introduction of the single-page application (SPA).
The adoption of SPAs has been sweeping and rapid, allowing developers to create powerful web applications that offer users an incredibly rich web experience. However, for all the benefits an SPA can provide, it doesn’t come without its challenges. As the technology has grown and SPAs are expecting to do more heavy lifting, they’ve become larger and more complex. This can make them difficult to maintain due to a variety of technical and non-technical reasons, earning them the moniker of “monolithic frontend applications”.
The answer to these challenges may well lie in the adoption of micro frontends.
What are micro frontends?
Micro Frontends is a conceptual extension of microservices to the front end, which aims to solve the “monolithic app” problem experienced by so many enterprises. The philosophy behind micro frontends is to think of the web application as a composition of features that are owned by different independent teams. It’s an architectural pattern that splits monolithic SPAs into smaller apps that can be developed, tested and deployed independently, while still giving SPA experience to the end-user.
The following image represents typical micro frontend architecture and integration:
As presented in the above image, each microapp is a standalone SPA with its own repo, technology stack, architecture and CI/CD pipeline. Microapps can also have re-usable components shared between multiple microapps, before integrating to form the final product/website. This integration is generally wrapped in a container application which brings the microapps together on one page, renders common components and handles cross-microapp navigation, authentication and more. Any of the following approaches can be used for microapps integration:
- Integration using server-side templates
- Build-time integration
- Run-time integration
- Using micro frontends framework
Covering the integration approaches is out of scope of this article.
Why use micro frontends?
1. Small and maintainable code
With micro frontends, you divide the entire product into groups of small features that, together, make multiple small web applications. All of these apps will have separate code and each app will be responsible for fulfilling specific business goals. This makes each micro app small and manageable over the long term, which has the added benefit of drastically simplifying testing.
2. Independent deployment
The ability to deploy a small set of functionalities without dependency on other modules greatly reduces deployment scope and complexity. With separate repos, each micro frontend app can have its own CI pipeline that builds, tests and deploys it into production. As each micro frontend is de-coupled from another part of the website, a team that builds and manages the micro frontend can deploy the app into production, even if other micro apps have functionality unimplemented or broken.
3. Independent and focused team
With de-coupled repo and release cycles, we can have a team that owns a small set of functionalities (a micro frontend app) through the entire software development lifecycle (SDLC). This gives a sense of ownership and autonomy to the team, enabling them to move quickly and effectively. This means each team can be aligned to a business goal rather than a technical one. This makes each team focused on a fixed set of deliverable goals with minimal friction and dependency on other teams.
4. Scalable development team
The autonomous nature of each team also reduces the dependency and friction between teams. Structured this way, more teams can work simultaneously on the project with consistent delivery performance.
5. Incremental updates
For enterprises, it’s very common to have large frontends with an old-tech stack. Similar to microservices, the use of micro frontends allows companies to break large workflows into smaller independent apps, and affords them the flexibility to select an appropriate tech stack right for the task at hand. This makes it easier to create, update and implement in accordance with changing business needs. Not only that, but it can be done in an incremental fashion while allowing different tech stacks to co-exist in the same project.
Getting it right
We’ve established that micro frontends are a powerful asset when it comes to managing large web applications, but this doesn’t come without cost. There are a few things that can go wrong with micro frontends if not applied in the right way, so it’s important to take them into consideration.
1. Duplicate code
With multiple teams working autonomously, it is very easy to create a ton of duplicate code across multiple micro frontends. Though having code duplication could be necessary for moving forward faster, it might not be good from a product perspective. So teams need to be mindful of code duplication and proper governance should be applied.
2. Managing state
In micro frontends, by design, each micro application manages its own state. This is different from traditional SPAs, where a centralized state management approach is used. Teams should avoid using shared state as much as possible. When required, pass state info from one micro app to another micro app using encoded URLs or other techniques.
3. Inter-micro app communication
Micro frontends rely on the concept of de-coupled applications. However, that may not always be the case. Sometimes inter-micro application communication is required. For instance, a navigation micro application would need to send out a notification that another microapp has been selected by the user from the navigation menu. You can use browser events or event bus for such requirements.
4. UI/UX consistency
With multiple autonomous teams working in parallel, it’s quite easy for a team to make decisions that might not fit well in terms of the product’s larger context. To overcome such problems, a proper governance structure should be adopted.
5. Loading time
With each micro application acting as a separate web application, the end-user is required to download more bytes for the microapp to work. This can increase load time or consume more bandwidth.
6. CI/CD complexity
Micro frontends will lead to having more stuff to manage like increased repositories, more build/deployment pipelines, managing infrastructure and managing domains. This would require a robust and automated infrastructure process.
What is next?
As the next logical step, microservices and micro frontends teams can be combined to form end-to-end independent and autonomous teams that are responsible for a specific set of features from the entire product. Each team owns its UI/UX, frontend development, backend development and database. Such small and focused product teams can be agile and very efficient.
Micro frontends can be a fantastic tool to address modern web application challenges, but they are not a silver bullet. Depending on the kind of product, how it’s divided into micro apps, existing team structures, business goals and more, Micro Frontends may or may not be the right choice for you.
If you would like to learn more about the benefits and challenges of Micro Frontends, get in touch with Apexon using the form below.
