blog
Micro-Frontend Architecture: 5 Reasons to Adopt It (And 1 Challenge to Consider)
Posted 7 February 2025
Last year we worked with one of the world’s largest financial services corporations to upskill their developers who were working on a large micro-frontend system. The company had chosen the strategy of using micro-frontends to allow for a faster and safer change management cycle, but with the relative scarcity of good quality documentation and training available on the subject, many of the coders were self-taught or learning on the job.
Any large organisation knows that this can be pose a significant risk – to build safe, robust and reliable software, developers need an in depth understanding of the fundamentals and inner workings of whatever frameworks they are using. We therefore created and delivered a custom course for this institution, covering Micro-frontends with React, with a focus on how it works, best practice, and identifying and understanding how to fix problems that can occur.
The evolution of micro-frontends
The way that software has been distributed has changed significantly over the years. In the early 1990s, if you wanted to buy a copy of Windows 3.1, you went into a shop, and purchased a set of 6 floppy disks. In the years that followed you would be purchasing CD-Roms, then DVD-Roms, until the ability to download software became more prevalent in the mid 2010s.
Fast forward to the 2020s and software-as-a-service has become the most widely used methodology. It’s estimated that 70% of all software developed today fits this model – that is rather than developing applications that need to be downloaded and installed, we are building applications that are hosted on servers and run in the browser. Whether the software is designed for internal use within organisations, or for sale to others, we have moved away from the idea of users needing to install applications to users gaining access to websites.
One of the key enablers of this change is the ability to do more in a browser with the advent of frameworks like React, Angular and Vue. Websites used to be pretty much static pages of information, where the user reads, clicks, and occasionally buys things. But modern browser based applications are almost indistinguishable in terms of functionality from the traditional approach. Microsoft’s Office365 or Google’s equivalent (Docs, Sheets and more) are great examples of how much can now be done in a web browser.
Building larger and larger web based applications, however, comes with challenges, and Micro-Frontend architecture is designed to solve some of these.
What exactly are Micro-frontends?
The idea of Micro-frontends was first developed in 2016. It takes the concept of micro services, and applies it to the development of browser based front-ends.
The concept of microservices has been around since the early 2010s and is now a widely adopted architectural style for development of server based applications. The idea is that rather than building one single application, instead we create a number of smaller independent applications that can communicate with each other. This approach can bring significant benefits on larger, more complex, applications, such as making them more scalable, and easier to test, deploy and upgrade.
Within this approach, the front-end, or user interface, is often seen as one single micro-service within the wider structure. But as the size of the code base for a single browser based application grows, this can lead to problems, and remove some of the benefits from the micro-service approach.
So the idea of micro-frontends then is to allow a single front-end application to be built as a suite of independent smaller applications (or micro-frontends), which can potentially communicate with each other. This then can restore the benefits of microservices within the larger picture, as well as bring some extra benefits to the front-end development teams.
From the user’s point of view, it’s just a single application – they don’t know or see any difference.
5 reasons to adopt Micro-frontend application architecture:
1. Easier separation of work across development teams
For larger applications, there can be many teams working on a single code base. Amazon, for example, famously operate development teams in team sizes that can be fed by two-pizzas (somewhere between 8 and 15 maximum). If you have, say, 100 developers working on an application, then these will by necessity need to be split into a number of smaller teams.
When this happens with traditional application development, it becomes vitally important that everyone in every team follows the same approaches, use the same styles, and understands enough about what the other teams are doing, so as to not break their work. The larger the teams, the more difficult this becomes, with significant efforts needed on communication and good management.
Compare this to the situation where each team can work independently and doesn’t need to know anything about the inner workings of the other teams. They will agree between themselves how their separate applications will communicate, but that’s the limit of the inter-team interaction that is needed. Now we have removed the dependencies and simplified the communication overheads, and in the process also removed the risk of one team breaking another team’s code.
2. Simplify testing
Before any update to an application can go live, it needs thorough testing. The larger the code base and the more complex the application, the more work is involved. Even where testing is fully automated, running a full suite of tests can take time, and if after a test-run, changes are needed to fix bugs, the iterative process is a slow one.
Where we have a suite of smaller, independent, separate applications, we simplify the entire testing process – where a change is being made, it is now only this single application that needs testing. This doesn’t just save time, but also makes finding and fixing the bugs easier too.
3. More robust systems
One of the nice features of microservcies is that should part of an application be unavailable due to a hardware or software fault, this doesn’t necessarily impact the entire application.
Because we have a number of independent applications if one were to crash, this wouldn’t stop the others functioning.
This same idea can be extended to the front-end. If a server hosting part of the suite of micro-frontends is unavailable for some reason, the remainder of the application can continue to function. This can mean that there is a perception of zero downtime for the application even if part of its functionality is restricted for a short time.
4. Less risky change management processes
This is perhaps the most important of all the benefits of micro-frontends. When we deploy a change we are deploying an upgrade to one small application, rather than the entire system. If that change is unsuccessful for some reason, then this as before doesn’t impact the entire application. A key point here is that each microservice is separately upgradeable and separately deployable.
5. Architecture and Systems Integration
The final benefit (and there are others, this isn’t an exhaustive list) is that with micro-frontends it is possible to develop an application using different technologies. Where it makes sense to do so, for example, you could build some microservices using Angular and some using React, and these can be seamlessly integrated together. Conversely when new versions of these frameworks are released, each microservice can be upgraded separately – there is no longer a need to more an entire application to a new framework version as a “big bang” exercise.
And one reason not to
You might be reading this thinking this all sounds great… using micro-services architecture does indeed bring a significant number of benefits, but it does come with a few challenges. It adds a degree of complexity to your environment and processes.
Setting up a micro-service structure requires you to think about and answer a number of questions, such as:
· How will you split up your application into separate independent smaller applications?
· How will you ensure consistency of design and user experience?
· How will you integrate the different applications in a consistent way?
Summary
Adopting a Micro-front architecture can bring significant benefits to larger projects, especially where there are multiple teams working on the same application. There is, however added complexity when switching to this approach, so you should consider whether it’s the best approach for each specific development scenario.
Want to learn more about our Software Architecture offering?
Our programs help organisations create a recognised group of solution architects ready to drive innovation and deliver exceptional results.
Get in touch with our team today to find out more.
