Micro Frontend Architecture

Knowledge / Inspiration

Micro Frontend Architecture

Continuous Delivery
UXDX Europe 2018

Summarising 2 years of work in 30 minutes, Luca will introduce you to his vision of Microfrotnend architecture. Luca is Chief Architect at DAZN - the Netflix of sport. Luca will discuss from monolith to micro. What is a Microfrontend. The principles of Microfrontend and the technical implementations.

Thank you very much, Joe. is it working? Can you hear me? Perfect, great, okay. So, first of all, thank you for choosing this session over the other. It's a pleasure having you here today. I'm very excited to be on the stage today because it's the first time I'm delivering this talk and, to be honest, it's also very challenging because I'm trying to summarise two years of work in 30 minutes. That is interesting.
So today I want to introduce you to my vision of a Microfrontend architecture. It's not a new topic, but there are many approaches that we can have. I would like to give you mine.
As Joe said, my name is Luca. I’m the chief architect at DAZN, DAZN is an OTT platform that is available in seven countries. We already have hundreds of developers. We have millions of customers. It’s a really interesting challenge because we have 30 devices that we have to keep on track and deliver our applications. We have a video delivery pipeline that is very complex. That's the Netflix source port.
I'm a Google developer expert on web technologies and I'm organising a lot of meetups with my community. So, if you are in London, and you're looking for a meet-up, we organise one per month, feel free to join us.
So, what we are going to cover today? So, first of all, we will do a journey from a monolith to micro anything, and then we were talking about, what is a micro frontend? We will define some principles around them and we will end up with some technical implementation or, let's say, different options that we can have to embrace this new architecture.
First of all, and foremost, this is, as I said, the first time that I do this talk. But to arrive at these ideas and concepts, I had to be very open-minded and question all the best software development practices that I studied in the past. So please be open-minded during this talk and think at scale, because this is one of the ways that you will better embrace this architecture.
Okay, so I joined DAZN four years ago, as a startup. We are still a startup in a certain way, despite the number of people that are working on DAZN. And I remember on one of my first days that I was there and the CPO came to my desk and said: “Listen, look up. I know that you are the second tech person that was hired inside this company, but at the same time I would like that you think broadly, and you start to think at scale because what we would like to have in DAZN is having hundreds of developers that are working on the same platform and the same codebase”.
And to be honest in a certain way as an architect, I was a bit scared because if you think about that, you know you are the second that joined the company as a tech person, and suddenly you discover that you already have to this huge challenge to think about an architecture that could empower developers in distributed teams across the world working on the same code base. So, it is a big challenge, so bear that in mind. Let's start this journey, that was basically the journey that I did to move forward towards the micro world, as I call it.
So, when you start a new project or if you work in a startup, usually what you care about at the beginning is retrieving feedback quickly from your potential customers right. So, the tech stock is important, but not essential. What you usually do is you tend to obviously, the time to market is more important. Therefore, you tend to maybe cut some corners. Usually, 90 % of the time what you end up having is a database that is shared across multiple APIs. You have an API layer that is storing what they call a monolith that contains all your API integration with third-party companies and so on, and then on the client-side, you have a single page application.
Single-page applications, I pick that architecture, just because, obviously there are several others that you can pick, server-side rendered, you can have single pages. But a single page application is one of the most used where you download the entire code base and then you just consume some API to render the view. And then when you validate your ideas and the company starts to grow you identify what are the areas that have to grow with the company and the organisation.
So, what you start to do is take your monolith, breaking it up into multiple microservices. You start to have one database for microservices because otherwise, it's an anti-pattern using a shared database for multiple microservice. You have your infrastructure that is dedicated to that, and then you start to divide your teams following the way the business works.
But what do you do on the client-side? On the client-side, usually, what you have is, I don't know, tens of developers that are working on the same codebase, how they started, and it's becoming more difficult every time, every iteration, because, if they're not very prescriptive in the way that they are working, you have a codebase that is exploding and it's way more difficult if you start to have distributed teams. Because with distributed teams it’s very, very hard, apart from having pull requests that you can check, what is the outcome of your codebase. So the impact with your team so usually on the front hand side, as we said, we have a unique code base that is managed by multiple teams. What we need to manage a lot is the communication overhead between different parts of the organisation, particularly if you have a distributed team.
Instead, if you check what is happening on the infrastructure side, so the website and back end side, they start to have a structure that allows them to scale independently, some parts have some strong boundaries around what they are delivering and everything becomes easier in a certain way because if they design properly their microservice in the API's, they just define a contract, and they stick with that and then they are complete autonomous to deliver a new microservice, a new version. There are a lot of engineering practices that you can use to ensure that your microservice is not breaking up the entire platform, also in production.
But on the client-side, it wasn't the same thing right. So, as we said, this is our situation, and I would like you to stick that in mind because this is how often these kinds of things are working, but what if we change this thing, what if we start to take the principles of microservices and apply them to the client-side? What if we start to say, that the domain-driven design is not only for the back end, it could be applied to those on the front end. At the end of the day, if you think about that, we have a monolith, we break it apart and we start to have multiple API's that are managed by multiple containers or I don't know lambdas or whatever you prefer to deal with, and then you start to have an infrastructure that is dedicated for certain microservice and you can have also on the front end.
You can break apart the SPA monolith, having some challenges initially, because you need to find a way to orchestrate which client, which microfrontend you want to load, but at the end of the day you can do that and you can end up on something under an architecture like that, obviously it’s a simplification, but why not?
So, if we start to begin a little bit further with that, we can start to see something very interesting. So, first of all, the impact to the team, because we don't think often as architects or too much on the process of how we structure the team. But we have to do that because if we want to scale your company, that is probably one of the most important things, in particular for the front-end. If you scale the front - and you don't have to scale infrastructure, because we are delivering the vast majority of the time static files, CDNs are doing that for us. What we need to scale and think about are the teams. Because that is the complicated part, but with micro frontends. We can start to introduce a way to speed up the throughput of our teams because we can have cross-functional teams that are managing the API layer, the infrastructure layer, and the front-end layer in autonomy. They don't have to communicate with other teams as long the contracts are respected. They start to have freedom and responsibility because they own the full stack end-to-end for the first time they can innovate. As we know, one of the pleasures of working with microservices is the fact that you can have multiple technology stocks, when you are designing your APIs.
We can do the same on Micro Frontends. Why you cannot have the part of your application written VueJS, part with React and Redux, and part with angular, it's feasible.
So, let's talk about what is a micro frontend now, so this is my definition. You cannot find much on the web, so I'm working hard to provide some information starting from a DDD perspective. “Micro front ends are a technical representation of a business subdomain and they provide strong boundaries with clear contracts and they avoid sharing logic with other subdomains”. That, for me, is a let's say and a definition that is providing clarity on what we are trying to achieve with micro frontends, and I would like to check the key part of this sentence. So, representation of business subdomain with strong boundaries and clear contracts and avoid sharing logic. So domain and subdomain is not a new concept. It is something that is applied in domain-driven design for a while and often domain driven design is, though mainly for back-end layers, but we should use only on the front end. So, let's see what is a domain, A domain is a problem to be addressed with the software effort. So, if you think about Netflix, I hope that everyone knows what Netflix is? The domain, for them, is an OTT platform that is trying to deliver movies with streaming. Okay, but, if we take all this domain or together, it is very complex, because there are a lot of things inside there that we have to think about, such as subscriptions, catalogue and so on, and therefore DDD, it is tending to say okay, so, if we have a domain, you can split it up into multiple subdomains, and usually, if you do that very well and you master the domain, you can start to map your subdomains also with teams, and that is very important because you can start to have the payment team and the infrastructure team and your front and the back-end team and the cross-functional team working together with the product.
And that is something very, very important. Because when you have that it means that the communication overhead starts to diminish a lot.
Another key concept of the micro frontend for me, is sharing nothing. And I know that it's very painful at the beginning because the first thing that we tend to do on the front end is okay, so I have to create my application. Some components are available in multiple areas of my application: let's create a component library. And trust me I spend a lot of time working on this topic with developers and they know what are the pros and cons of this. I know that there is a lot of resistance at the beginning. So, if you think about the microservice, usually with the microservice, you share a little bit that usually are logs and monitoring and often are not even inside your code, what if we can do the same on the front end. Honestly what we have done so one of the things that usually we have in DAZN, a lot of people are saying: We have multiple micro frontends and we have the header and footer that are replicated. I don't know five-six times - copy and paste and then changed. And a lot of people are saying: oh, yes, but that that is a bad practice because we are copying code and every time we need to change, we need to change five times. But the question is how often the header and footer are changing during the lifecycle of a platform.
So, I checked that thing and we changed twice in three years. So, is it a problem? The fact that we are adding a new label inside the header or we are changing the colour of the font. I don't think so. I think that the throughput is way more important and then thinking, okay, we have to deal with this duplication of code and, if it's well addressed, it is not a big deal.
So how we can approach micro frontends, because there are several ways to do that. As I said, it's not a new concept, but we are trying to find the right way to do that. For instance, Spotify, in the desktop application they work with iframes, it's a desktop application that is based on web technologies for the UI and the C++ behind the scene. And what they are doing is creating multiple iframes that are their micro frontends and inside the view there is, I don't know, the micro frontend for the music player they have, I don't know, what your friends are listening to. There is the list, the catalogue micro frontend, and they communicate together via an event that is injected inside micro frontends. That is one option. The question here is how we can properly assemble these views. Probably there is another team that is doing that, probably the responsibility of a specific team, but still, there is a lot of communication going on.
Opentable, another large organisation, they have distributed, teams in Australia, London, and San Francisco. They started this journey of micro frontends in 2014 if I remember well. And they created a developer experience team that delivered these open components as an open-source project where when we define a component, is a front-end, back-end, and style, and everything server-side rendered component that is stored inside the registry, think about docker, if you're familiar with that. And every single team can pick up from this registry, the components that they want and they compose the application without much communication at the end because if there is a team in Australia that is creating, I don't know header. Then it could be used anywhere else. Some coordination has to happen on this side of the cross-region, but in the end, it’s an interesting approach.
That is another approach for micro frontends as well, obviously for making a smoother experience for developers they also created CLI. But that means at the same time that a new joiner in an open table has to learn all these things and start to use all the tools that are available inside the company.
The third example that is the one that is closer to my ideas - is Zalando, fashion e-commerce. Several years ago I attended a talk made by one of their engineers and the interesting bit there is that they created an open-source framework on the mosaic, and there is a specific part called Tailor.js, and what Tailor does is created at runtime that your pages. Basically there is a tiny layer that every time you request a page, they are assembled HTML fragments on the go. They are highly cacheable because when you have like, I don't know track-suit from Adidas, it would be always that you don't have to serve something specific. But in that case, they can do that they can work at scale. They produce these pages they cache on CDN, and that's it. Tailor is written in Go. It was one of the first experiments that were so pretty brilliant for the forefront and written in Go. They were inspired by a BigPipe from Facebook, so you can see a BigPipe on Facebook pages, it's more or less similar, but also in this case we are talking about components that are assembled at runtime on the server.
We took a different approach in this case because of one thing that I was thinking when I was designing this architecture. So now we have like one or a small team of developers start working on one platform that is the web, but we need to target 30 platforms. We also need to have distributed teams that are sharing the same codebase because they have to work on the same codebase and who knows what could happen next. So, the first thing that I did was take our application if you think Netflix is very similar and I work with the domains, so I started to slice and dice my application in multiple subdomains.
So, we have the Landing Page subdomain. We have the Authentication that contains a sign-in/sign-up, retrieve email, retrieve pass for payment altogether. We have Discovery and Playback where we have the core of DAZN where we have the catalogue, we have search functionality; we have schedule functionality and we have the playback. Then we have the Customer Support where we have the help and the chat, the contact hours and so on. And we have My Account where you can change a few of the things.
So those are the key domains that we have subdomains, that we have inside the DAZN domain and those are mapped one to one with our product team. So, we have a product team that is managing payment. We have a product team managing the acquisition. We have a product team for managing the landing page. Sometimes the product team is composed of one person only sometimes say, compose more people. Discover and Playback is pretty huge, for instance, but this is how we structure things, and each single of these areas are represented technically speaking with a single page application. So, each of them is a single-page application. Some of them are not even sharing the same technology stack. Some of them are based on React and MobX, some others just React. We are doing some tests with other technologies, but all of them are completely different projects managed by different teams.
And in order to orchestrate this, because the complexity of this is not creating multiple single-page applications is how we deliver to the client, and I spend a lot of time thinking about that and at the end, what they came up with in order to avoid scalability issues because the problem that we have compared to the Zalando is we need to create something that is highly scalable, that is completely customised, for the user, therefore, we cannot use too much the CDN right now for serving our content, because there are too many permutations. So, I created this layer. This is called the bootstrap and is the first thing that is downloaded when you type www.dazn.com. It has a few things to do the first thing is the application startup so it just understanding which platform the user is watching DAZN and retrieving the configuration for that specific country, then, is obstructing the input-output operation for all the other single-page applications or Micro frontends, because one of the problems you have when you work on TVs in particular, is that the API for writing something on the APIs is completely different between a manufacturer or in the same manufacturer, between different Smart TVs editions. So, if you have a Samsung or Samsung Tizen there are completely different APIs to write that. So, therefore, if each single microfrontend should know this kind of permutation, it means that we need to create one for every single platform. But honestly, we can abstract that, and the bootstrap is doing this.
The other thing is doing the routing between micro frontends, so he understands in which state the user is and then based on that is retrieving them the right micro frontend. So, you understand if the user is signed in and if it's signed in it will go straight to the delivering playback. If it's not signed in, it will start to serve the landing page unless there is a deep link and that case is going to the authentication page, for instance.
The last thing is: it's sharing configuration across multiple micro frontends, so in that case, because it's a vanilla, just layer that is just exposing some stuff, we are just exposing things that are happening in one micro frontend and making it available for other micro frontends to listen to that.
Also, for instance, I don't know marketing pixel or analytics like Google tag manager stuff like that are living inside the bootstrap and the bootstrap is the key of our strategy because if you think about that, we need to deliver Around 20 Smart TVs applications and if I start to have like the domain-specific code inside every single micro frontend. it's impossible for us because we need to have so much effort to make it right, that is very difficult. Instead, if I abstract that on the bootstrap is very interesting because it becomes very natural. I can reuse authentication everywhere without changing anything.
The other interesting thing about this is that we can do it on the delivery side we can do something that is unique. Because we can, for instance, maintain the current application delivery, just a subset of the functionality of this new architecture without impacting the user. So, potentially we can say, 30 % of our users are receiving the discovery in playback micro frontend, instead of the previous application, that is a single page application, but at the same time I can reuse all the rest for maintaining the authentication, landing page stuff like that.
So, this architecture allows us to deploy wherever we want, whenever we want in a specific country and ease gradually the new version of a micro frontend as we can do with microservices. If you think about it, I don't know Bluegreen’s deployment of Canary releases, we can do the same thing with this architecture.
So, if we think about this, what we have gained with a micro frontend. So first of all, and foremost micro frontend is not a component is a representation of a sub-domain that is matching exactly the structure of our organisation. Its technology, and framework agnostic. As I said where I can develop one micro frontend in one technology and use another one for another micro frontend. Then each micro frontend exposes a lifecycle method that is used by the bootstrap when we want to unload the micro frontend or mount a micro frontend doing some things inside that. Each team inside the micro frontend can share components, code style and any other stuff like that, but they cannot do that outside the micro frontend, because that is going to slow down everything. I work in a lot of large organisations managing hundreds of developers and when you start to abstract and have a team that is centralising code is where the throughput is going nuts because you start to have a centralised version of your code and every time you need to change, you need to do additional abstraction. The code became more difficult to maintain and the six-month time the throughput is gone.
Studying this way we can isolate the team that can pick the data and they can take their own decisions and they can innovate inside that. The other interesting thing with this: we can test different building systems. One micro frontend could be built with, I don't know, Webpack or another one with the parcel and so on, so we can have a less granularity of choice that we can do with, and this is brilliant.
So what did we achieve? So first of all, that is for me pretty interesting. We were able to onboard five teams in a couple of weeks so after the first week, they were able immediately to contribute to the codebase because they are completely independent. They don't have to wait to deeply understand the architecture they have like their single page application. That is tiny. The domain is small, they can understand the domain deeply and then they can go, and start to work on that.
We have currently over a hundred developers that are working on the same code base. That is brilliant because I also have a distributed way because we have people in Poland. We have people in London and we are opening a new centre right now in Amsterdam, and that is one of the powers of this.
Finally, the developers have the freedom as the possibility to innovate and own the code end-to-end and not just part of that, because often, too often, architects are thinking just on the API layer, but it's not the API layer that is that the complex one because currently we have a lot of way and patterns and architecture that could help us to scale it up but for frontend, we don't have much.
So, if you want to start to look deeply at micro frontends, I pick these two projects. There aren't many as I've seen as I've shown before you can have an open component. There are other ways to do that like Tailor.js, but the two things that for me, are closer to my mind's. Those are the two frameworks. One is Single-SPA that is not well known but is providing a structure that is very similar to what we are building. Unfortunately, I discovered that too late in the process, like a year after we started to work on this.
A really interesting one and then FrintJS. FrintJS provides slightly more flexibility and freedom compared to Single-SPA, but another interesting one is leveraging reactive programming behind the scene and you can create components with different frameworks, and the FrintJS as well collect them and show them inside their task folder. So, this is an interesting one as well.
To wrap up. I would like to just summarise what we have seen till now, so when we scale frontend application, the problem is not scaling the infrastructure, it’s scaling the teams - and we have to take into consideration this because it's very important to have the right throughput to reduce the communication overhead between teams.
Last but not least, developers are moving from one company to another one, and I don't know how’s the industry here, but in London, they are changing more or less every year and a half, mainly because they want to try something new. But with micro frontends, you are providing them what they are looking for inside the organisation and also it could be a good way to retain people.
Last but not least, I'm working right now on, if you're interested, to know more about micro frontends because in 30 minutes it's very difficult to summarise everything. I’m writing right now, a report for O’Reilly that would be a free report probably will be available by the end of the year. I’m doing some learning sessions. One will be the 18 of October online that is fully free. You can check out my social profile and hopefully, from next year, I will be able to dedicate some of my time to writing a full book on micro frontends.
That's it for me. I know that we have some time for questions, but if we are not able to speak right now and question anything I'm around here for whole two days, so please feel free to stop me and challenge all the ideas that they share because, as I said at the beginning it is two years’ work and we are going to the path and having a fresh point of view, it could only out. Thank you very much.