How Hopin is Moving 10x Faster: Microfrontends at Scale

Great. Well, thank you, everyone, for joining my talk, and thank you, react advance, for having me here today. We're going to run a little experiment. My laptop wasn't working, so I'm going to be like a DJ with two laptops at the same time and I have one connected to the other one. Let's see how it goes. So today we're going to be talking about how Hoping is moving ten times faster with micro frontends at scale. First let me introduce myself. My name is Alex Lobera, and I love react, typescript, of course, micro frontends, Salsa, Bachata, and my partner, and not in that particular order, of course. I work for Hoping, and as a senior staff engineer, and you can find me on Twitter, in Alex Lobera. This talk is about micro frontends architecture, and in any architecture, everything is a trade-off, right? We are constantly making decisions about what is best for the job. We are weighing different options. Let me fix this. We're in a react conference, so I guess react weighs more. We're always weighing what is the best option. In order to understand the architecture, you need to understand the context. Let me share with you the context in our application, or in our organisation. Hoping has acquired different companies. We have here an example. The way we organise is by product areas. Then we have teams that work on those products. Companies have technology stack. In the case of Hoping, we use react. Jam uses vue. We might want to mix and match technologies across different products. Very important, teams work in the same UI. We have small teams, and you can have a single page that has different features, and every feature is owned by different teams, all together in the same page. We want those teams to be able to work very quickly without stepping on each other's toes. So now what is our definition of micro frontends? For us, micro frontends is an architecture, and we think of it as a software application where we break up apps into a collection of smaller apps, and they have a series of characteristics. First, they are organised around business capabilities. They are owned by a small team. They're independently deployable, and, very important, they're loosely coupled. Here for instance, we have a UI, and there is two features. I'm going to call them apps because for us, features should be able to work independently without the context of the larger app. Here we have a chat and a user profile. Then every team is going to be able to deploy them independently. They will build them and deploy to a CDN. Then we use webpack to pull those dependencies using module federation, and we integrate them at run time. Once we have those scripts, what we do is we mount them on independent component trees. Here we have two features, two applications, and so we will have two independent component trees with two roots. We might want to share some state between them. We don't encourage engineers to share a state between the micro frontends but there are some cases where we might want to do that. To do this, we have a very lightweight store that is going to enable teams to share some state. It is a very simple store. It cannot derive a state, for instance, like Redux or Recoil. We believe they're too powerful for this paradigm, so we have a simpler implementation that will push all the state logic inside the boundaries of each application. Again, our goal is to have a very decoupled system. Let me show you a demo. Now is when things get funny. First of all, I'm not using my laptop. I'm going to switch to the other laptop. Here what we have is some react app. We are rendering it here. You can see the component tree. I can move over the tree and see that I'm over the input. You see the input highlighted on the UI, the same for the button. I can look at the network tab and I'm pulling some dependencies. I can filter by react here, and you can see I download react and react DOM because we need those to mount this application. But I can also look at this in the context of a next.js application. Here, if I look at the component tree, I can see this component, this is the next.js app, I can scroll down, and when I get to this point in the tree, I see that I'm highlighting the user profile but I don't see the input and the button that I saw before. So we have this mount micro front-end. I can scroll down and I can see another tree. I can see my input and my button here. So there are two distinct trees. I can also look at the network tab, and if I filter react, I see that here I'm not downloading react or react DOM because in the context of the next.js application, webpack is sharing those libraries with the react app. Let's have a look at this mount micro front-end that is receiving some URL and some name. So I'm going to switch to the other laptop. Okay. WebStorm, how do I make things larger in WebStorm? I don't use WebStorm. Does anyone know if I do a command? Say again? Oh, that was too easy. react advanced, thank you. You learned something. I did. So, let's go back. I'm going to look at this mount here. And I want to look at the mount function. So what I do is I receive a URL, and that URL, I will load some scripts. When this is ready, it means module federation is ready to load some script, some module in this case. What I'm going to load is the profile. And I have it in here. This is the entry point of that application. Notice that I'm not exporting components. I'm exporting a function that has an argument which is an html element, and what I'm going to do is I'm going to mount my app on that element, and I'm also going to return an unmount function to clean up this. So I can go back to the other laptop, and I'm going to collapse this, and I can go to the chat, then I'm mounting this other application, this react app, I can go back to the home page and, you know, mounting and unmounting. Why do we do all this? The reason we're doing this is because we want to decouple our applications, and if we render everything in the same component tree, then we could potentially add some Redux or whatever on the context, and then all my small applications would use that implicit context, right? And so that's bad, right? Because if tomorrow I change the next level application Redux or something else, then I also need to change my other applications. So here, for instance, we have a provider, and if I want to use this provider on the other side, I will need to also add the provider in the context of the other application, and then what I will need to do is I will need to explicitly wrap it from one side and pass it to the other one, right? When I mount in this create root, I get the context from one side and pass it to the other one. So the reason we are doing this is because we want to create boundaries, and that's very helpful. That's very helpful because, well, before... So one thing we can do is, speaking about the context, I want to show you this provider that we were looking at, this ReactiveMap provider. This is the lightweight store that I mentioned before that we use, and so I can use it, for instance, to add some name, right? I want to change the name on one side of the application, but I also want other places in my app to react to it. So if I change the name to Alex, then this reacts, which is a different application. I can look at the profiler, and I can maybe add something here. Record. Save. See what happens. And only my chat was the application that reacted to it and was rendered. So this is really nice. Now we have boundaries, and we can mix and match as I was saying before. Let's say we have a vue.js chat that, you know, it's just a chat, and just for the purpose of the demo, I'm not saying we should do this, but let's say we want to replace react with vue. And so I could go to this other laptop, and in the page where I'm rendering, when I'm rendering this, I'm going to change for 87, right? I have on this board, I'm running the vue.js application, so what I'm going to do is I'm going to change this, and now, if I go to the other app, and I reload the page, I don't have the vue.js application which is very interesting. Sorry, I got it. I'm getting confused with this laptop. So if I change it in the right place, and now I go to the other laptop, and I reload this page, I have the vue.js application. I never thought I was going to get this round of applause for showing vue.js in a react conference, but you never know! So I can look at the elements and select this div here where I have this next-js application. It's highlighting the entire app on the browser, and I can select this, I have this vue.js inside the next-js application, and it actually works. I can also change my name, and it also reacts to it. Similar, it's the same experience, the same as I did before. Why is all this happening? Because we are creating boundaries between our applications, and because we have explicit contracts. If we comply with those contracts, everything should work. Okay, so, I go back here. So that's cool. That kind of works, but what if I go that path and I have 100 applications, maybe one, I don't know, many applications, react component trees in my app, what is going to happen? Is this going to be performant? I don't know. Maybe some of you are wondering that. So I thought of preparing a demo for this. And I have this benchmark which I'm going to... so, here, what I have is one react app that can't mount many apps. If I look at the component tree, I have one app that can mount many other apps. You can see the create root here as we have on the other side. I can render, let's say, ten apps, so I'm mounting ten applications here. I can also say, okay, I'm going to render ten components each. Now I have ten apps with ten components. We can see the memory on the left, and on the right, we have a clock. I'm changing that using javascript, so, if the thread gets really busy because we're mounting and calculating trees, then it will freeze. So let's do an experiment. If we run maybe, we don't have a lot of time, so let's go straight to 30,000 components. See how long it takes to render on my laptop 30,000 components. So that's going to be around six seconds. Let's do it again just for fun so I can waste a bit more time on this. 43 is going to be around 49. Six seconds. Okay, nice. It's consistent. So, what if I render 3,000 apps? How long is it going to take? It was two or three seconds. Let's do it again. Same two or three seconds. Let's do the final test then. Before we render, we mounted 30,000 components, so now let's mount 3,000 apps with ten components. That's going to be the same, right? Let's refer. What do you think is going to happen? I have three minutes left, so let's go to it. Ten. Oh, that was interesting. Wait. Four or five. So what do we learn here? Well it was faster. I have some benchmarks I want to share with you here. I did it with 100,000 components and a few combinations of those. As you can see, memory-wise, it didn't change much. The time to display those changes was different. react will take more time to render many component trees. However, it is not only react, you need to paint those changes, and the sooner you start painting, the faster it is. As you can see, the more you increase the numbers, there is a significant difference here. So, all in all, it won't make your app slower to do this. I'm using react 17. I expect this to be probably insignificant maybe with react 18. The point here is you don't do this, you don't break your app into many apps because it is smarter, faster, you do it because you want to create boundaries, because you want to decouple your code and your applications. So some principles, create boundaries, you can create multiple component trees, it is safe. Use explicit contracts. Use explicit contracts if you want to share some state or context from one place to another, make it explicit, get it from one place and pass it to the other one. If you decide to share some state, I recommend you to keep the state logic inside the boundaries of your app, and, for us, we use very simple store that cannot derive a state. It only communicates stage changes. We believe that Redux and recoil, for instance, those tools are too powerful for a paradigm like this. You can still use Redux but you use it inside your app, not to communicate between your apps. Thank you very much! APPLAUSE. All right. Step into my office, pal. Let's have a chat. DJ Alex! Wow, I made it. I didn't think of it. Alex. Micro front-end, huh? Yeah. I'm going to have to get a little bit of a break. I'm going to have to get a little bit of a break. I'm going to have to get a little bit of a break. I'm going to have to get a little bit of a break. I'm going to have to get a little bit of a break. I'm going to have to get a little bit of a break. I'm going to have to get a little bit of a break. I'm going to have to get a little bit of a break. We have one question from the audience. Remember you can ask questions at slide.do. The code is 2225. And they want to know, how do you ensure styles don't bleed between apps, especially if apps are legacy and use global selectors, shadow DOM question mark, and apps aren't mutating shared packages? Well, you want to scope namespace your styles, and you want to make sure that if you use like style components, probably you want to avoid using global estate, because, you know, it will, it might have the same scope for different packages if they are completely independent. So I would say try to avoid global estate for sure. Global css and global styles, and namespace your classes. Good tip, good tip. Finley wants to know, how do you enforce the contracts between different micro apps? In the end, a contract is, you know, it's a function with arguments for us, and what you do is you can have two types of checks, run time checks, which we do, like if you try to access something that you should not, then you will get an error, and we also use typescript. The reason we use run time also checks is because sometimes engineers like to use TS ignore, so it's good to have a backup plan. I never use TS ignore. You shouldn't either. Billy asks, is it faster to render multiple apps with components rather than the other way around because of how react reconciles changes, large tree versus multiple smaller ones? I don't know the exact answer, but my hypothesis is that you will start painting earlier as opposed to calculating more things, because what is slow is painting the UI, not javascript. javascript is much, you know, cheap if you like, than modifying the DOM. So the sooner you start doing that work, then the faster it is. Cool. Anna asks, would you recommend micro front-ends plus vue plus WebStorm? Is it a great combination to introduce? I would add to that maybe using two laptops is not a good idea, but I think, you know, horses for courses. You need to find the problem and then use the right tool. And I don't know, like maybe in some context, it makes sense to do that. I would say it all depends on the context and the requirements. But try not to use too many laptops and too many frameworks at the same time. Probably is a good idea. There's a question in here about Hopin specifically that I want to read and also add a little bit to. Steph asks how many engineers work on front-end at Hopin and how was the decision to go micro front-ends architecture made? And to that I want to follow up. Is there any sort of process or like organisational effect that it has on either teams or devs on whether they work on one app or multiple? Yeah, that's a good question. So when I joined nine months ago, my department, my product area had 12 engineers on an XJS app. Now we are around 60 in the same XJS app. So that's too many people in the same place. So you need to find a way to, for people to work independently so they don't step on each other's toes. And the way we operate is more like decisions are made bottom-up, so, you know, some people will say, okay, we have this problem, we'll solve it, and then others will try to socialise that idea and use it. So it's more a decision of we have this problem, then we started building our own framework, if you like, and then now other departments are using these tools too, yeah, which is pretty cool. Influencers. Yeah, I would say that. This is a very popular one. It's got a lot of thumbs up. Which state management do you recommend to use to communicate between apps? Obviously, the one we are building. So the thing is, we didn't find any state management tool that was good enough for the job because they are all too powerful, and that kind of encourages developers to, you know, when you get power, you use it. So we wanted to create something very simple, and, for instance, deriving a state in that is not a good idea because then you have this centralised thing that has logic, and so we had to build something that was much simpler than the things that we found in the community. So the answer is hopefully one day we'll be able to open source it, and I'll show you, but I would say the one we are creating. You should follow Alex on Twitter for that news when, if it comes. We unfortunately don't have time for more questions, but Alex and Ruben are going to have a hybrid discussion room later around 2.10, just off the stage here if you want to ask them more questions or get advice on micro front-ends. Thank you, Alex. You're free to go. Cheers for Alex, please. Thank you.