How Hopin is Moving 10x Faster: Microfrontends at Scale

Rate this content
Bookmark

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.

25 min
22 Oct, 2021

AI Generated Video Summary

This Talk discusses how Hoping uses micro frontends to improve development speed and create boundaries between applications. They break up apps into smaller, independently deployable apps owned by small teams. They use webpack and module federation to integrate dependencies at runtime and have a lightweight store for sharing state. The Talk also addresses performance concerns and the importance of explicit contracts and namespace styles to avoid conflicts between micro frontends.

1. Introduction to Micro Frontends Architecture

Short description:

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.

2. Micro Frontend Architecture and Demo

Short description:

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.

3. Mounting the Application and Cleaning Up

Short description:

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.

4. Decoupling Applications and Creating Boundaries

Short description:

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.

5. Creating Boundaries and Performance Demo

Short description:

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.

6. Performance of Rendering Multiple Apps

Short description:

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.

7. Sharing State and Using Explicit Contracts

Short description:

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.

QnA

Micro Frontend Styles and Contracts

Short description:

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.

Working Independently and State Management

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn