The micro service architecture is a method of developing a software system using multiple small modules. It has gained popularity as it aims to solve the challenges monolithic systems have presented. Simply put, they help build an application as a suite of small services, each running individual processes and being independently deployable.

As front-end codebases become more complex, there is a need for new ideas to tackle the challenges this brings. Micro frontends are the same idea as micro services, applied to the front end. Let's think about it in the context of a frontend application, for example, a web application; you can think of it as many small applications stitched together to give the illusion of a unified, larger application. I have had a positive experience using this approach and decided to share some of my experiences whilst adopting this on a complex web application.

A monolithic application can quickly become hard to understand, navigate, and tightly coupled. You may have already hit this point, and it is the reason for researching micro frontends in the first place. If that is the case, all is not lost. You could still adopt this pattern, and it may be advantageous. In contrast, a micro front end is a smaller, more straightforward chunk, usually with a single responsibility. You can avoid the hassle and cost of a total rewrite by refactoring aspects of your application piece by piece into smaller applications. In the meantime, you can continue to deliver new features as new applications without being held back.

Each micro frontend should have an individual deployment pipeline, which builds, tests, and deploys your code. There are a few benefits to this:

If a pipeline fails, it doesn't prevent other areas of your application from being deployed.

It reduces the risk of introducing a new error that affects the entire application.

Less surface area for your test coverage allows you to write more meaningful tests.

Autonomous teams can work independently on their designated application if you are a larger organisation. Each team can have clear responsibilities without worrying about the application as a whole.

Have you found yourself stuck to a specific framework or library and wanting to experiment with the latest technology? For most monolithic applications, this significant decision affects the entire organisation. You must weigh the pros and cons and consider whether it's worth migrating your codebase or adding a new dependency. However, with a micro frontend architecture, you can experiment on smaller applications with less consequence.

Building a user interface is a challenging task. There are many things to consider:

Does it match the organisation's brand identity?

You must ask yourself these questions every time you develop a new component, from a button to a modal to something more complex. Once you have solved a problem for a specific component, you don't want to do it again. A common approach to solve this is to create a reusable component library of user interface elements. Generally, this is best practice, but it is necessary for the context of micro frontends, so you don't have to reinvent the wheel across multiple applications. Components should have a fully typed public interface with strong, consistently-applied conventions. This way, other developers or teams don't need to worry about the underlying implementation.

Wait, isn't this what we're trying to avoid? Not exactly. We can successfully set up the micro front-end architecture within the context of a mono repo giving us the same advantages but all the benefits of our code existing in the same repository. There are powerful tools, such as 

, which enable you to build a suite of libraries to be shared across multiple applications, all inside a single repository. Each application is independent and can have a unique deployment process. If you wish to expand outside this repository, you can publish the libraries externally, giving you the best of both worlds.

We've only touched on a few points here about the benefits of micro frontends, but it is important to be aware that there are always trade-offs in software development. It is about splitting up a project into more manageable chunks. Still, if not implemented correctly, it can lead to duplication of dependencies, larger bundle sizes and fragmentation between teams (sometimes that fancy new framework isn't always the best choice!)

As frontend codebases become more complex, there is a need for new ideas to tackle the challenges this brings. Micro frontends are the same idea as micro services, applied to the frontend. 