Hopin is the fastest-growing startup in the world. Many engineers join every month. Companies with different technologies are acquired every other month. It brings many challenges to our front-end architecture. In this talk I'll explain how we're breaking up our React monoliths and enabling interoperability using multiple React trees and reactive variables.
This talk has been presented at React Advanced 2021, check out the latest edition of this React Conference.
The speaker is Alex Lobera.
The main topic is how Hoping is moving ten times faster with micro frontends at scale.
Alex Lobera works for Hoping as a senior staff engineer.
Micro frontends are an architecture where apps are broken into a collection of smaller apps that are organized around business capabilities, owned by small teams, independently deployable, and loosely coupled.
Hoping uses micro frontends to allow small teams to work quickly without stepping on each other's toes and to mix and match technologies across different products.
Hoping uses React, while another acquired company, Jam, uses Vue.
Hoping uses webpack's module federation to pull dependencies and integrates them at run time, mounting them on independent component trees.
Hoping uses a very lightweight store that enables teams to share some state without deriving state, unlike more powerful tools like Redux or Recoil.
Hoping scopes and namespaces styles to avoid global state and ensure styles remain independent for each app.
When Alex Lobera joined, his product area had 12 engineers, and now it has around 60 engineers working on the same Exodus app.
Decisions are made bottom-up, where people identify problems and propose solutions, which are then socialized and adopted by other departments.
Today we're gonna be talking about how Hoping is moving ten times faster with micro frontends at scale. In order to understand the architecture, you need to understand the context. Hoping has acquired different companies. We have an example. The way we organise is by product areas. Then we have teams that work on those products. Companies have technology stacked. In the case of Hopping, 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 with each other's toes. So now what's our definition of micro front-ends? So for us, micro front-ends 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're organised around business capabilities. They're owned by a small team. They're independently deployable, and very important, they're loosely coupled.
Great. Well, thank you, everyone, for joining my talk, and thank you React Advance for having me here today. We're gonna run a little experiment. My laptop wasn't working, so I have, like, I'm gonna be, like, I feel 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.
Today we're gonna 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's best for the job. We are weighing different options. We're in a React conference, so React weighs more. We're 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 an example. The way we organise is by product areas. Then we have teams that work on those products. Companies have technology stacked. In the case of Hopping, 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 with each other's toes. So now what's our definition of micro front-ends? So for us, micro front-ends 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're organised around business capabilities. They're owned by a small team. They're independently deployable, and very important, they're loosely coupled.
Here we have a UI with two independent features, a chat and a user profile. Each team can deploy these features independently by building and deploying them to a CDN. We use webpack and module federation to pull the dependencies and integrate them at runtime. We have a lightweight store for sharing state between micro frontends, pushing the state logic inside each application. In a demo, we show how different component trees and dependencies are loaded based on the context of the application.
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, we mount them on independent component trees. So here we have two features, two applications, so we will have two independent component trees with two routes. We might want to share some state between them. We don't encourage engineers to share a state between the microfrontend but there are some cases where we may want to do that. To do this, we have a very lightweight store that is going to enable teams to share some state, and it's a very simple store. It cannot derive a state, for instance, unlike Redux or recoil. We believe they are 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. Here is the first experiment. I'm going to be switching to the other laptop. So 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 if I'm over the input, you see also the input highlighted on the UI, same for the button, and I can also 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. And 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 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, 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 because, in the context of the application, it's 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. I'm going to switch to the other laptop. Okay, WebStorm. How do I make things larger in WebStorm? I don't use WebStorm.
I receive a URL, load scripts, and mount the app on an HTML element, returning an unmount function for cleanup.
Does anyone know, like, if I do a command plus? Say again? Oh, that was so easy. 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.
We decouple our applications using micro frontends to create boundaries. By rendering each application in its own component tree, we avoid implicit context dependencies. We use a lightweight store called ReactiveMap provider to share state between applications. This allows us to change specific parts of the app without affecting others. We can even mix and match different frameworks, like replacing React with Vue, by simply changing the rendering location. This gives us flexibility and the ability to create boundaries.
So I can go back to the other laptop, and I'm going to look, 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 mounting and unmounting. Why do we do all this, right? The reason we're doing this is because we want to decouple our applications, and if we render everything in the same component tree, 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. 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 route, 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 happened. 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. The purpose of the demo, I'm not saying we should do this. Let's say we want to replace React with Vue. I could go to this other laptop, and in the page where I'm rendering 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 ... And I reload this page, I have the Vue.js application. Whoo! I never thought I was going to be like getting 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. Notice that it's highlighting the entire app on the browser.
I have this Vue.js inside the Next.js application, and it actually reacts to changes. We create boundaries between our applications and have explicit contracts. I prepared a demo to address performance concerns. I have one React app that can mount many other apps. Let's do an experiment with 30,000 components and see how long it takes to render.
And I can select this, I have this Vue.js inside the Next.js application, and it actually I can also change my name, and it also reacts to it. Similar, 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. As long as we comply with those contracts, everything should work.
Okay. So I'll go back here. So that's cool. That kind of works, but what if I go that path and then I have 100 applications, maybe one, I don't know, many applications, React component trees in my app. What's 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 are 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. Let's 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 little 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, three seconds. Let's do it again. Same two, three seconds. Let's do the final test. Before we render, we mounted 30,000 components. Now let's mount 3,000 apps with ten components. That's going to be the same. What did we learn here? It was faster. React will take more time to render many component trees. However, it is not only React. You also need to paint those changes, and the sooner you start painting, the faster it is. So, all in all, it won't make your app slower to do this. The point here is you don't do this, you don't break your app into many apps because it's smart, it's faster. You do it because you want to create boundaries, you want to decouple your code and your applications. Use some principles, create boundaries.
Okay, nice. It's consistent. So what if I render 3,000 apps? How long is it going to take? It was two, three seconds. Let's do it again. Same two, three seconds. Let's do the final test. Before we render, we mounted 30,000 components. Now let's mount 3,000 apps with ten components. That's going to be the same. Let's refer. What do you think is going to happen? I have three minutes left. Let's go to it. Ten. And, oh, that was interesting. Wait. Four, five. What did we learn here? 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 also need to paint those changes, and the sooner you start painting, the faster it is. 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, but the point here is you don't do this, you don't break your app into many apps because it's smart, it's faster. You do it because you want to create boundaries, you want to decouple your code and your applications. Use some principles, create boundaries.
You can create multiple component trees and use explicit contracts to share state or context. Keep the state logic within the boundaries and avoid using powerful tools like Redux and Recoil for inter-app communication.
You can create multiple component trees. It's safe. Use explicit contracts. Oops! Use explicit contracts if you want to share a state or context from one place to another, make it explicit, get it from one place and pass it to another one. If you decide to share some state, I recommend you to keep the state logic inside the boundaries For us, we use a very simple store that cannot derive a state. It only communicates stage changes. And we believe that Redux and Recoil, for instance, those sort of 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! Thank you. Thank you. Micro front ends, huh? We have one question from the audience. They want to know how to ensure styles don't bleed between apps, and how to enforce contracts between different microapps. Good tips are to namespace your styles and avoid using global estate. Runtime checks and TypeScript can help enforce contracts. As for rendering multiple apps with components, starting painting earlier can make it faster. The choice of tools depends on the context and requirements. It's important not to use too many laptops and frameworks simultaneously. The decision to go Microfrontend architecture at Hoppin and its impact on teams and developers is an interesting topic.
Thank you very much! Thank you. Thank you. Alright. Step into my office, pal! Let's have a chat! Let me close both laptops. DJ Alex! Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Wow! I made it! I didn't think of it. Breath.
So, Alex! Yeah! Micro front ends, huh? Yeah, that's the topic. We have one question from the audience. 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? 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 components, you want to avoid using global estate because 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. So global CSS and global styles, and namespace your classes. Good tip. Good tip. how do you enforce the contracts between different microapps? In the end, a contract is a function with arguments for us, and what you do is you can have two types of checks, runtime 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, and the reason we use runtime also checks is because sometimes engineers will like to use TS ignore, so it's good to have a backup plan. I never use TS ignore. Me neither, but I saw it. You shouldn't either. Billy asked, 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 cheaper, if you like, than modifying the DOM. So the sooner you start doing that work, then the faster it is. Cool. I want to ask, would you recommend Microfrontend plus view plus Webstorm? Is it a great combination to introduce? Well, I would add to that using two laptops is also not a good idea, but I think courses for courses. You need to find a problem and then use the right tool, and, I don't know, 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 a good idea. There's a question in here about Hoppin specifically that I want to read and also add a little bit to. Steph O. asks, how many engineers work on Frontend at Hoppin and how was the decision to go Microfrontend architecture made, and I also want to follow up, is there any sort of process or organisational effect that it has on either teams or devs on whether they work on one app or multiple? Yes, that's a good question.
When I joined nine months ago, my department had 12 engineers on an Exodus app. Now we are around 60. We needed a way for people to work independently. We operate with bottom-up decision-making and built our own framework. We are developing a simple state management tool. Hopefully, we will open-source it in the future. Follow Alex on Twitter for updates. No more questions, but there will be a discussion room later.
When I joined nine months ago, my department, my product area had 12 engineers on an Exodus app. Now we are around 60 in the same Exodus app. So that's too many people in the same place. find a way for people to work independently so they don't step on each other's toes.
The way we operate is more like decisions are made bottom up, so some people will say, OK, we have this problem, we will 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, like, and now other departments are using these tools too, 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? So obviously the one we are building. So the thing is, we didn't find any state management tool that was good enough for the that are too powerful, and that kind of encourages developers to, you know, when you get power, you use it. And 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 will be able to open source it and I will show But I would say the one we are creating. You should follow Alex on Twitter for that news, when if it comes. Yeah.
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-Frontend. Thank you, Alex. You are free to go.
We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career
React Advanced 2022
Remix Conf Europe 2022
React Summit Remote Edition 2021
React Advanced 2023
React Advanced 2022
React Summit 2022
React Summit 2023
React Day Berlin 2023React Advanced 2021React Summit Remote Edition 2021React Advanced 2022
React Advanced 2021
Comments