How micro-frontends make our developers’ lives easier
7 min read
For the past two years, micro-frontend architecture has been gaining popularity and support. Breaking down frontend monoliths encourages team autonomy, eliminates many scaling issues, and diminishes time to market, which is crucial for any business. I’ve personally explored and driven this architectural decision on a large-scale project and, since joining Nord Security, I’ve been delighted to make the most of micro-frontend architecture as an engineer.
It was an enlightening but bumpy ride, so I want to share some of my thoughts and ideas before you decide if micro-frontends are right for you.
What are micro-frontends?
The complexity of web applications has exploded recently. The monolithic approach could no longer meet business and development speed requirements. Microservice architecture has already saved backend developers from this burden, but many frontenders still struggle with growing monolithic codebases.
On top of that, the frontend ecosystem is evolving rapidly as well. Tools and frameworks change constantly. Inspired by the success of microservice architecture, frontend engineers began looking for ways to split up the frontend monolith. This would improve the developer’s experience while maintaining application integrity for users.
The clearest path to that goal is micro-frontend architecture. British software developer Martin Fowler defines micro-frontends as “an architectural style where independently deliverable frontend applications are composed into a greater whole.” In other words, we break the monolithic frontend application into smaller independent frontend parts. Those interconnected parts make up the whole application.
Do you need micro-frontends?
Dan Abramov, a software designer at Facebook, can help answer this question. “The problems [micro frontends are] supposed to solve sound to me like they’re already solved by a good component model. So is this solving an organizational issue rather than a technical one? Such as if two teams can’t agree on anything, even shared infra.”
Frontend developers must regularly differentiate between business logic, visual components, logical components, utilities, etc.. This is nothing new. This sort of modularity introduces clarity to the code base and some level of scalability to the web app.
Simply selecting an existing frontend framework often predetermines the architecture and how to scale. For many projects, this decision is sufficient and should be the first step before ever considering micro-frontend architecture. However, additional modularity is required when businesses undergo rapid growth phases. Growing businesses need to change more dynamic code parts fast and keep ahead of their competitors. They wind up needing more engineering teams as their organizational structures increase in complexity. In this context, application-level modularity might not be enough. Micro-frontend architecture could be the missing component that makes the difference.
As with any architectural decision, micro-frontend architecture helps solve both technical and organizational challenges. The same was true at Nord Security:
- Some of our applications have too many different business domain logic structures that are part of the same codebase but are otherwise unrelated;
- We needed to share small parts of our logic and UI across several different related web applications;
- Many of our changes were being made to small pieces of the codebase.
Separating applications and giving teams full ownership of their codebase allowed us to develop faster, deploy only those code parts that were changed, isolate the scope of any resulting errors, and of course, test smaller portions of code faster. Aside from these perks, we are able to continue to reevaluate each micro frontend and split it even further if necessary. It was easy to see how micro-frontend architecture was the right choice for us.
In addition to the aforementioned perks, micro-frontends enable gradual technological migration and allow technology independence. For example, it becomes possible to run multiple frameworks in the same browser window. However, this use case can introduce performance and compatibility issues and additional cognitive load for the engineers. This can be a useful method for technology migration or experimentation, but it should be used with caution. Which leads us to my next point…
No silver bullet
One must consider the potential drawbacks of micro-frontend architecture as well. According to Luca Mezzalira, a solutions architect at Amazon Web Services, there are four foundational pillars of micro-frontend architecture:
- Definition: We define the size and scope of the micro frontend;
- Composition: Where and how we will stitch our micro applications, components, or widgets together;
- Routing: We define what needs to be loaded for the customer;
- Communication: How and when our micro-frontends should communicate with each other.
Each decision has its pros and cons. A client-side composition could save tons of company resources and scale horizontally very well. However, if SEO is essential for the business, edge-side or server-side composition is the way to go. Another example is micro-frontend splitting. Splitting on the component level might seem very attractive, but this can introduce other challenges, like shared dependency versioning and page layout ownership.
Finally, engineering departments and teams need to make sure they’re all in sync. Having different approaches across teams will only introduce additional issues and slow you down in the long run. At the end of the day, all micro-frontends are part of the customer journey and must create an uninterrupted and pleasant user experience. Standardized communication between every step is essential for both developer and user experience.
Implementation at an organizational level
Since micro-frontend architecture is still a fairly new approach in the industry, it is crucial to onboard engineers with the decision and architecture principles. Skipping this step might lead to quite a few misunderstandings or even micro-frontend anarchy. There are different ways to implement this architecture, so all of your engineers should understand how your company plans to implement it.
Presentations, workshops, open discussions, sharing the latest insights from experts – these are all valid tools. At Nord Security, before writing any code, we created multiple presentations regarding micro-frontends and how we imagine them. We shared insights and podcasts from other companies and industry experts. This put our engineers, quality assurance people, and managers all on the same page. If you’re interested, I suggest following these people:
- Joel Denning
- Luca Mezzalira
- Zack Jackson
- Michael Geers
Don’t forget the business side of the organization. If business teams often create tasks that impact multiple parts of the application, using micro-frontends could prevent them from reaching their fullest potential. Discuss this architectural shift with stakeholders to increase collaboration and break down silos. On top of that, working with business people on this topic could provide great guidance on how your micro-frontends should be separated.
Don’t make mountains out of molehills
When discussing architectural reworks, many engineers immediately imagine building something from scratch or rewriting a lot of code. And sometimes, that might be the only choice. However, the Javascript ecosystem accepted micro-frontends as an architectural choice and began supporting it with tooling. The release of Webpack 5 introduced Module Federation functionality. Similar to that, we have the initiative to implement import maps, which is also supported with systemjs. Finally, the old and controversial iframes could also do the job.
With these technologies in place, the shift to micro-frontends can be gradual and smooth. It will be easier to test and identify the right micro-frontend size. Gradual code separation from the monolithic frontend won’t detract from business feature delivery either.
Conclusion
For some projects, micro-frontend architecture can be a great way to take scalability, testability, and developer experience to a whole new level. Players like DAZN, Spotify, and Ikea have confirmed this. However, each of them underwent a long journey before adopting this approach. Each journey lets that company best fulfill its needs. Research, iterative experimentation, and organization-level knowledge sharing will pave the way for a successful micro-frontends journey and enable companies to make the best out of it.