This is a term that has been growing for past years. But, what is exactly a micro frontend?
Introduction
Since the dawn of the internet era, we have been writing code to make the web interactive. For the past decade, the term web application has became a thing. All this time the frontend code was just a big, solid and entangled monolith.
When we think about the backend tech, the microservice approach has been widely used to structure independent applications that can communicate and reach an objective on the user journey.
But... what if we could use this approach to the frontend dev?
The monolith
When we write web apps, we usually choose a framework to help us (React, Vue, Angular, Svelte, and others) and architect it over layers such as models, views and controllers. All the code happily lives in one great repository.
Time passes, people come and go, new techs are born and raise, and there is our monolith. But we know that systems must evolve, otherwise it becomes a cumbersome old code that does not perform well or is difficult to maintain.
What if we now need to change the tech stack of the frontend? Well, it would be a big problem to change anything without breaking the whole application. But that's just one downside of the monolith, let's see some more:
- As the monolith grows, it becomes more and more difficult to understand all of the code and draw a clear line of the business requirements
- Big compiled javascript monoliths can take a long time to build
- Even if we change a little part of it, we need to redeploy the whole application
So, how can we breakdown this big app and turn it into multiple independent applications?
The micro frontend
This term has been wandering around the internet since 2015. Check below this trend from Google. As we can see, the interest rate has been continuously growing since late 2018.
Micro frontends follow the same principle as microservices on the backend. Each application lives independently and has a well defined objective.
Let's think of a very simple example: an e-commerce. To build up such an application, we can expect the following requirements:
- Home page to show the recommended products
- Cart page
- Checkout page
- Payment page
Each one of this pages can be written as a single application. When we breakdown a monolith like this, it is also possible to breakdown into specialized teams.
There could be some developers writing just the home page, a couple other maintaining the cart page, and so on.
The following picture from the must read Martin Fowler's article represents this:
Using this approach also helps to integrate with the microservices built by the backend team. We can pick the frontend devs that build the home page, with the backend devs that build the microservice of the home page. So now we have a full team which only objective is to code the home page! Check out the following picture from Michael Geers article:
Advantages
A micro frontend architecture can deliver the following advantages:
- Very easy to change the tech stack, since each application will naturally contain less code and will not interfere in other apps.
- Fast maintenance: as each application has one concern, a bug can be easily spotted and adjusted.
- Fast deploy: it's easier and faster to build and deploy little applications.
- Easy scaling: each application has its own scale requirement, so we can easily provide different environments.
Disadvantages
Every decision has its disadvantages, and it's not different with micro frontends:
- There must be a special attention to shared libraries between applications, so the browser won't download the same lib multiple times.
- Code redundancy: some code may be repeated on each application. We surely could write a helper application that others use, but that would create a tight coupling between them.
- Architectural complexity: it's way easier to manage a single monolith than multiple applications. To overcome this, there must be some automation and a lot of documentation to help developer experience.
Building a micro frontend
Well... now that we know what is a micro frontend, how can we build it?
To breakdown a front monolith, we have some techniques:
- iframes: using this (old) approach, we can have a single page with multiple inner applications, each one in a different iframe.
- WebPack Module Federation: this recently launched approach aims to bundle different applications using WebPack. Here we can define how apps depend on each other and share common libraries.
- import-map: this is the strategy used by the single-spa framework. Each application javascript file is exposed by an address and the import map register them, enabling an orchestrator to know where each one is located.
- Web Components: each application can be represented by a custom HTML element that could be orchestrated by a host application
Some great frameworks out there can help into building micro frontends:
- single-spa: allow micro frontends by using import-map and an orchestrator that handles routing and communication between apps
- Luigi: powered by SAP, it uses iframes to build micro frontends
- Piral: uses modules called pilets to deliver a modular architecture
- Frint: a complete framework that delivers routing, state management, server rendering and other features to micro frontend architecture
Conclusion
As we could see, this theme is pretty recent and new techniques and frameworks are still walking to help us develop micro frontends, but we can see that it has tremendous advantages to web development.
I hope you all liked this content! See you soon!
Top comments (19)
In my personal opinoin the effort required for such implementation does not match its value unless you have a very specific business requirment. and this doesn't provide all the upsides of microservice implementation. for scalable frontend setup Nx & React might be interesting to check out.
It surely is a huge effort! An approach to slowly migrate old apps and to ease this implementation is to use the iframe technique, just like @dastasoft said.
I think the typical case to assume that effort is if in your company there are two different frameworks (or more) and you need to build a new application that has some parts with legacy code and the new projects are with React for example.
For example when you log into Amazon or Paypal sometimes you navigate to a screen that looks very legacy, imagine that scenario in an app that you can't navigate completely to "somewhere else", there I think it becomes very useful.
One additional thing is that any solution other than iframes will make you change the project. Many companies can adopt a new architecture if the product is new and you are in the planning phase, but if you have a lot of projects already done, frameworks like single-spa don't fit at all.
So my bet is that if any company starts migrating to this architecture they will choose iframes because they can combine existing projects with new ones more easily.
I will keep an eye out for changes to the Webpack Module Federation as it looks very promising.
Thanks for sharing!
Single-spa can bring together many UI frameworks (not just SPAs). Check out their website, it’s pretty impressive.
And unlike iframes, you can still test it really easily. Iframes have all kinds of challenges in UI testing.
Yes, you can combine them, but you have to adapt existing projects, that's the real problem with legacy projects.
You are definitely right! Iframe is commonly picked to help companies migrate their monolithic apps.
What about design and usability consistency? If you split the front in parts like these, they may look and feel different from each other because of different implementation approaches to the same design - and here I'm hoping there is going to be a single design to the whole system.
Hey Jonatas! Your concern is very valid. This problem is commonly solved by using a design system application that makes components available for other applications.
As every app will be using these components, the general look and feel will be the same. Something like that:
Stencil.js can be used build framework agnostic component libraries. Apple use it in their design system
That's nice to know! Thanks for sharing.
Might I suggest for those wanting to move in the direction of MicroFrontend look at building separately compiled npm packages with shared dependencies using project templates in order to strategically plan a migration strategy for legacy apps.
I am currently in progress with this in my day-job and it's working out great. I am migrating a monolithic Angular app to React, so I am building libraries (collections of React components) that contain a single feature and/or related pieces in order to segregate the purposes of a given application. This allows me to include them in the shell app (the monolith) as an npm dependency and then later, at my choosing, move the npm dependencies to webpack federation or another means to remotely host and version them to lazy load them at runtime.
It's a stepping stone to MicroFrontend, but it certainly enforces the same patterns and ideas without the immense burden of using single-spa or another MicroFrontend tool. The great thing about React is you can just use ReactDOM.render() in order to render the precompiled components you want within an Angular (or whatever framework) component with lifecycle hooks to ensure proper creation, update, and garbage collection.
I'm not sure but Twitch does something similar to this. They have video team that maintains the video player, chat team to maintain the live stream chat, etc
Iframe SEO :(
Yep :( iframes have huge downsides like security and SEO. That's why the most fit technique must be picked by each company.
When you say, "huge downsides like security", can you be more specific in what you are referring to?
Hey Michael!! In terms of micro frontend maybe iframes don't expose big security problem as long as the same origin is preserved and the X-Frame-Options header is set. This mitigates attacks such as Clickjacking and XSS.
This is very informative, thank you!
Thanks Wassef!