For the past year or so, Birdie has been experimenting with micro frontend architecture. We have converted our primary front end application into smaller applications and we’ve seen some great results. In this post I aim to break down what a micro frontend application is, why we moved to it, and what we’ve learnt along the way.
What is Micro Frontend architecture?
We’ve seen over the past few years many software companies break up their software into smaller chunks. The aim here is to have more applications, that are quicker to test, simpler to maintain and have clearer boundaries. While there is complexity introduced with breaking up these applications, the trade off is often worth it.
We’ve particularly seen this in the backend as teams have broken apart large monoliths into smaller micro services. This idea is that each of these services has a specific job and the resources for them can scaled as needed.
Micro frontend architecture borrows from this philosophy, breaking up large Single Page Applications into small apps held loosely together with some form of shell. On Martin Fowler’s page dedicated to this topic it describes it as follows:
an architectural style where independently deliverable frontend applications are composed into a greater whole.
If you’ve worked with micro-services then it’s not a huge jump to see that on the front end. For those that haven’t let’s break it down some more.
Let’s take a contrived example: a social network for bird spotting. With the main page you have 3 sections: the navigation bar, the profile of the user and the feed of birds that other users have seen. Each of these areas has its own job to do and could be broken up into its own front ends that displays each section. This would all be held together in an app wrapper, or shell. Each application (navigation, profile and feed) would have its own code base and would be deployed separately from each other.
As we experimented with micro frontends we found there were 3 main benefits to us as an organisation: improved deployment time, true team autonomy and improved developer experience.
Ship it
As we scaled as a business, both in the number of features being built and the number of engineers in the organisation, we encountered a number of problems with the way we developed front-end applications.
To start with we had one single-page application built with React that talked to an API. We started small and then grew and grew as we partnered with more care agencies and started to solve the problems they were facing. Before we knew it we had a bulky, monolithic frontend application, spanning multiple teams and multiple problem spaces.
From the very start we have had a strong culture of testing; something we could write a whole blog post about. Our mission is to improve the lives of millions of elderly people and so we are dealing with sensitive and important information. We needed to have confidence in our code base, both in assuring that what we had written does what it is supposed to and that it didn’t break anything else. Over the years this meant that there were a lot of tests. These tests include unit, integration and end-to-end tests. To run all of these tests in one go was taking more and more time.
This was slowing down our development and deployment. Before any Pull Requests would be able to be merged we would need to have all the tests pass. The same for pushing to the staging and production environments. This is all good practice and “The Right Thing To Do”. But it was getting to the point when one team was working on adding ‘Feature C’, we were running tests on ‘Feature A’ and ‘Feature B’ (ie other sections that the foremost section didn’t touch) — slowing down our delivery on getting a feature into users’ hands. It was becoming untenable and ineffective.
This was one of the driving reasons for us to start experimenting with Micro Frontends. When each section of the application is broken down, the related tests go with it. This meant the time taken to fully test the micro frontend would be minutes rather than hours. Also, by creating that separation of concerns with the micro frontends, we had confidence that when we were working on one application that it wouldn’t affect the code in another. This meant that we still had a high level of confidence in our code and were also able to ship more quickly.
True team autonomy
Here at Birdie, we believe that an empowered team is a good team. When a team is given a compelling vision and is trusted to make their own decisions about how they can help the organisation reach that vision then great things happen: Innovation increases, morale multiplies and the quality of output is higher.
This belief permeates its way throughout the whole organisation and it is no different in the Engineering chapter. Each squad is given autonomy to work how they like and use the tools they think are best to use to solve the problem they are investigating.
A problem we encountered is that teams can’t truly be autonomous if they are having to use the same frameworks and tools as everyone else. Take our large, single-page application for example; it is a large React Single Page Application that uses Styled Components, Redux, Sagas and a whole host of other great tools.
However, what happens when the best tool to solve a new problem clashes with one that’s already there? And what happens if a team actually wants to use a different state management tool such as XState? Sure, we can include it in the app but we start to face performance issues with larger and larger bundle sizes.
This is where Micro Frontends start to shine. Each squad owns a certain area of the our care agency-facing application. When that area is broken out into its own Micro Frontend the team is able to use the right tool for the job. It also gives the team the opportunity to remove old tools that were good before, but cause more problems now.
To enable this to happen we chose to use Single-Spa as our tooling of choice. This enables us to use any Javascript framework (or just plain vanilla JS) and it provides tooling to hold everything together.
A more focused Developer Experience (DX)
The development experience for working on a Single Page Application isn’t horrific. Download the repo, run the package manager, set some environment variables and run the app. Job done. This was not a problem for us that needed fixing.
However, there were a number of side effects of moving to a MFE architecture that made the developer experience really nice. Single-Spa uses an Import Map to know where all the bundled files live of the applications it needs to load. It also provides a developer tool for within the application shell (the bit that holds all the micro frontends together) to easily override the import map with a different URL. This can be a URL to somewhere else on the internet or to somewhere on your local machine.
Now the process of getting up and running with an application includes an extra step: updating the import map of the Staging environment to point at your running app. Even though there is an extra step, in reality, there is less work that needs to be done. Let me explain.
The truth is that to get the legacy frontend application working fully you need also really need a number of microservices running locally. Which involved having a couple of Docker containers running. Yes, you could point everything at a Staging/Pre-Prod environment but this still involved setup that wasn’t baked in. Also, due to the large size of the monolithic front end app, finding the part of the application you actually want to work on isn’t always straightforward. This is especially true for new joiners.
The result we found with moving to a Micro Frontend architecture was that the cognitive load of working on the front end became smaller. You no longer had to make sure everything could run locally. You could plug in the application you where working on and have a simplified code base to work on, increasing your focus. There was no need to worry about negative side effects of your code on other parts of the application because it was completely separate. This meant engineers could solve the problems they needed to without too much outside noise.
The more I work in software engineering on the web (and I’m getting to the stage of my career where old ideas are becoming fashionable again — vanilla CSS and server side rendering anyone?) the more I realise that one of the biggest skills to develop is understanding all the tradeoffs and picking an option because or despite these tradeoffs.
There is very rarely a ‘right’ way of doing this with software architecture. What works for one company may not work for another. What is important is being able to see all the constraints, the opportunities and dangers with any specific approach.
Micro frontends aren’t a silver bullet, they have their own challenges that come with the complexity they introduce. What we’ve found is that the benefits we gain through quicker deployments, truer autonomy and increased developer experience mean that this trade-off is worth our while. For now at least.
We’re hiring for a variety of roles within engineering. Come check them out here:
