This article was originally published on .cult by Doug Neale. .cult is a Berlin-based community platform for developers. We write about all things career-related, make original documentaries and share heaps of other untold developer stories from around the world.
If you’ve ever worked on a large codebase, you’ll know that it can suck. Their highly-coupled code and increased deployment risk can slow developer productivity right down. To combat this, many have shifted away from monolithic applications to smaller, more manageable pieces through microservices.
However, this has largely only affected the backend world while frontend codebases — with their ever-increasing complexity — remain monolithic. But in recent times, teams have begun to adopt the philosophy of microservices into frontend development by implementing micro-frontends.
What are micro-frontends?
It’s a practice that splits a single web application into multiple smaller, standalone web applications but is presented to the user as one. A page can be viewed as normal, but behind the scenes, multiple components of that page are fetched from different locations and stitched together on load.
The 💜 of EU tech
The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!
A notable example of this is the Spotify client. If you were to browse for an artist and then view the artist page, you would have unknowingly loaded both views from a different web application. If you’ve got the “Friends Activity” sidebar open, that would be a third micro-frontend.
There are many ways to implement this — all with their own strengths and weaknesses. Javascript injection, web components, and even iframes can be utilized to combine the views on load, as detailed in this walkthrough by Cam Jackson.
Why use micro-frontends?
More important than the how is the why. And there are many reasons why a company should consider a micro-frontend approach to their frontend codebase.
Sets clearer boundaries between teams
Just as with microservices, breaking down codebases into micro-frontends makes a product more manageable for teams. Large codebases become increasingly sluggish to work on and team productivity can take a hit from a complex local development configuration, bug fixing, and deployment risk management. Having smaller applications dedicated to certain features allows teams to work on relevant code in isolation. Then they can worry less about how changes affect other parts of the product.
Allows easier tech upgrades
The flexibility of a new micro-frontend allows for incremental upgrades as it can use a new web framework. If a product-wide upgrade is needed, teams can introduce a new technology feature-by-feature, instead of investing in a risky, big-bang release of an entire rework.
After this is complete, any future upgrades to the stack can also be implemented incrementally. Every dev knows how fast the frontend world moves — you know these upgrades will come.
Increases developer productivity
You may be thinking this all sounds unnecessarily complex. Some code duplication and boilerplate are naturally going to occur between micro-frontends — Luca Mezzalira admits that. But he stresses that, when making decisions, it’s important to consider the context of that decision. For many situations, the benefits of micro-frontends outweigh this overhead.
When HelloFresh first adopted microfrontends, they noticed a slowdown in productivity – developers now had to configure their new projects end-to-end. But once this learning curve passed, they reported a boost in team productivity, thanks to an easier development experience, and reduced deployment risk.
Summary
So for companies finding themselves with a complex and sluggish frontend codebase, micro-frontends are a useful technique for developers needing to scale and maintain their applications.
Get the TNW newsletter
Get the most important tech news in your inbox each week.