Adopting a Micro-frontends architecture

Considering the great feedback of the first post on micro-frontends and the questions received about the approach we are taking in DAZN, I decided to share a bit more about this topic.
In this post, I am covering one of the many possible implementations of a micro-frontends architecture.

Despite micro-frontends are a new model for our frontend applications, many companies tried to embrace the principles behind them and they have created multiple implementations for solving their frontend and organisation challenges.

I think is worth mentioning some of them before jumping in how we have designed our implementation, this is not an exhaustive list but it’s interesting being aware of the different possibilities available:

— Spotify uses micro-frontends in their desktop application leveraging iframes for stitching together different part of the same view.
The communication between iframes is made via an event bus that decouples nicely the different part of the application allowing them to communicate without knowing who is going to listen for a message or event.
Also, this approach saves a lot of time on managing the application memory because every time we change the iframe location, automatically all the objects are ready to be garbage collected.

— IKEA decided to implement micro-frontends with a different approach, they are using Edge Side Includes (ESI) mixed with Client Side Includes (CSI), I don’t wanna spend too many words on this technique because it’s extensively covered in Gustaf’s post but it’s definitely another opportunity for generating dynamically the content of our pages and cache the result on the CDN level or client side, depends the approach we wanna take.

— OpenComponents is an interesting framework used by several companies like Skyscanner or OpenTable. OpenComponents is an opinionated framework that is levering the concepts of an end to end components (frontend + backend together) submitted to a register and used for composing an application.
Also, in this case, we can find a lot of information on OpenComponents project website

In between those 3 implementations, we can find similar flavours with some differences used by medium-large size organisations for creating independent and technology agnostic micro-frontends. It’s worth mentioning Zalando or BuzzFeed for instance as other contributors in this school of thoughts.
If we wanna summarise the implementations we discussed till now we can list the 3 different approaches:

. using iframes + event bus
. using ESI in conjunction (or not) of CSI
. using OpenComponents or similar runtime/compile time template systems

The “DAZN way”

As I mentioned at the beginning of this post, there is another implementation to discuss: the approach taken in DAZN.
DAZN is an OTT service available in several countries that streams live and on-demand contents. Our application is available not only on web and mobile but also on smart TVs, set-top boxes and console, and that’s important to highlight because we often face unique challenges and we need to think out-of-the-box for solving them.

Usually, when we start a micro-frontends project, we should ask ourselves several questions and based on the answers facing the challenges related to our decisions, for example:

· do we want multiple micro-frontends in the same view?
· how do we route between pages?
· how do we share data between micro-frontends?
· how do we generate our micro-frontends? Runtime or Compile time?

Let’s try to answer all those questions for understanding the approach we embraced…

Do we want multiple micro-frontends in the same view?
No, we want to have 1 micro-frontend loaded per time in this way we don’t have share dependencies between micro-frontends, every micro-frontend is small enough but not too small, we have full control on the final outcome, it’s technology independent and well encapsulated.
We can potentially work with different versions of the same framework without impacting other micro-frontends or even with different technologies without any impact on the overall application.
We follow Domain Driven Design (DDD) practices for slicing our subdomains and make them really independent mapping the product teams structure and creating a vertical inside a large organisation composed by product people + frontend developers + backend developers + manual QAs + devs in test, and this is very powerful for moving fast, with different speed between teams when is needed in large companies.

Bear in mind that more often than you think, our applications are not entirely consumed by users, for instance, when the user is authenticated, all the code and the dependencies of the sign in/sign up micro-frontend won’t be loaded because we load only the micro-frontends of the authenticated area.
At the same time, when a user is not authenticated, it’s not 100% sure that she is going to finish the on-boarding journey and successfully access the authenticated area of your application, check your stats on how your users are interacting with your application and if you don’t have them invest the right amount of time on creating the right observability with tools like Google Analytics, Sentry, LogRocket and so on.
Remember, micro-frontends are helping a lot achieving the goal of loading only what the user needs and not more than that.

How do we route between pages and how do we share data between micro-frontends?
There are several ways we could achieve that, on the backend, on the edge or on the client side. We choose the client side creating an orchestrator called Bootstrap that has 4 main goals:
· route between micro-frontends
· load and unload a micro-frontend (1 per time, never multiple)
· initialize the application retrieving the configuration
· expose an APIs layer for sharing data between micro-frontends

How do we generate our micro-frontends? Runtime or Compile time?
We prefer to be very predictable with the outcome of our artefacts and we want them highly cachable like a SPA would be, therefore we didn’t take the path of creating anything at runtime, but we prefer generating micro-frontends at compile time, store them on AWS S3 and serve via Cloudfront CDN.
In this way, we don’t have to worry about scaling our infrastructure or unpredictable edge cases happening when we serve our application, we can run end to end tests and performance test before deploying in production having more confidence of what we deploy before being live.

The architecture

In our case, we decided to split the application into multiple subdomains studying upfront how our users were interacting with our web application. For green-field projects, I recommend to deeply understand how your users are going to interact with the application in conjunction with your UX and Product team and follow Domain Driven Design for defining the subdomains and their associated bounded-context.
For the DAZN application, almost every subdomain technically translates into a Single Page Application, but there are some exceptions, for instance, the video player is a component due to the broad scope of that subdomain, then those components are imported inside a micro-frontend as any other library.
Micro-frontends are loaded and orchestrated by the bootstrap, a simple vanilla javascript application embedded in the main HTML page that loads different micro-frontends based on deep-link requests, user status or any request coming from the loaded micro-frontend.

This is how our architecture looks like:

Bootstrap is always available during the lifecycle of our application, it’s responsible for loading our micro-frontends and exposing a tiny layer of abstraction between the device and the micro-frontend.
This detail becomes even more relevant when you target multiple devices and not only web browsers, we have our applications available on many smart TVs, set-top boxes and consoles, all of them have often different requirements and I/O APIs that defers and can be encapsulated at the boostrap level.
In this way, we can run a micro-frontend in multiple devices without the need to change a line of code because the bootstrap is abstracting the platform where the micro-frontend is running on.

If we wanna summarise how the application loads inside a browser we could say:

1. users request our web application typing our domain in the browser
2. bootstrap is served
3. bootstrap initialize the application retrieving some configuration from the APIs layer
4. based on the initial state and the user request (deep-link or default URL) load the correct micro-frontend
5. the user enjoys our web application based on micro-frontends !

Bear in mind that every micro-frontend is independent, therefore we are not sharing components or logic across micro-frontends.
If you think it is a waste of time and effort you won’t believe how much independence every team has got thanks to this decision.

Code duplication is not always a bad practice as we have learnt in the past, often cross-team dependencies and code abstractions risk to be way more dangerous and tedious than creating 3 or 4 times the same component.
We have noticed that spending the right amount of time analysing the user flows and identifying the subdomains lead to way less duplication than expected.
Also, we noticed using micro-frontends, the dependencies across teams didn’t happen too often like in other projects thanks to the initial effort on analysing the project and create meaningful subdomains.
If in your case it’s an absolute must re-using components, there is a way to mitigate the duplication using web components for standardising the component code, with this technique, it could be reusable in combination with any framework, but this is a discussion for another post .

When we started this journey into micro-frontends, for me was very clear that I had to think for the future of the development teams and not only solving the technical aspects.
With micro-frontends, we were able to provide the independence I was looking for without impacting the speed of delivery, each team is owning end to end a specific domain guaranteeing an easy way to add new functionality, fixing a bug or add an improvement without risking to have a knock out effect on the rest of the application or dependencies spread across our multiple dev centres.

Having shared those information several times with new developers joining the company as well as during my talks or online workshops I know you could have millions of questions around the bootstrap, how it loads a micro-frontends, how it shares data and so on.
I will answer all those questions in the next post that will be focused on bootstrap only so follow me for not missing this deep dive inside the micro-frontends world.

If you have any curiosity or question about micro-frontends feel free to get in touch, I’m always keen to help the community as much as I can !