Challenges of Decomposing a Massive Front-End Using Micro-Frontends

It's a nice, sunny day. You're gliding across the fjords. The nice sun rays fall on the lush forests and those fjords. You are dreaming to have this vacation for a long time. You are truly happy until something gets wrong.

Water consumes you. You lose control. You don't understand what's happening until you wake up. It's been a dream. It's been a bad dream and something has clearly woken you up. You take a look at your phone and you see that it is a pager duty notification. You have a duty to do.

Annoyed, you wake up. You stand up and lazily go to your computer to see what has happened. After some minutes of looking into the issue, you understand what the problem is. Nevertheless, you are extremely annoyed that it's caused not even by your team, but somebody who is not even a frontend engineer.

You hit the table because you're angry. You forget you have a kid who is woken up by your anger and now you have to explain your son why your father, Keith's father, has to fix a mobile phone validation library at night. You do the fix. You open the pull request, which takes 40 minutes to build. You make a coffee while you wait, and in the end instead of a happy green checkmark, you get a red cross.

Wakey test again. You click the restart button. You finish your cold tea to see your green checkmark. You merge your pull requests. You can go sleep for a couple of hours until you're going to wake up and do more job.

It's an example of a combination of a technological problem and an organizational challenge. It shouldn't have happened. Nevertheless, it's there. Microfrontends is one of the potential solutions to address this problem.

Thank you all for coming here. My name is Alex, and today we are going to talk about microfrontends. I was fortunate or fortunate enough to work in three companies which did microfrontends. Those were fairly different companies, and they wanted to share their experience. How did they do it? Also, dispel some stereotypes which surrounds the topic of microfrontends in general.

Let's talk about your company. You're working and you get an idea. You want to do something very straightforward, very simple, very tangible, and it's going to have very predictable and clear output. Seems easy, right? Let's do X and we're going to get Y. Very straightforward. But no, there is a guy with opinions, and now you have to convince him how you're going to do this. And at least his point makes sense, like, understand, okay, I see where you're coming from. Let's have a chat. Unless discussion expands. Expands in dimensions you didn't envision at first. And the further it goes, the more it deviates from the place it started until eventually it's gone.

Please raise your hands who can relate to the story. Many people. And people who are sitting around you, people who are part of those calls, they don't really want to be there. They also have life to live and they have kids who don't want to know about phone libraries. There is a lot of research about this. It's not a bleeding-edge subject. There was Fred Brooks. He was an engineer and engineering manager, like, many years ago, before many of us were even born. And he wrote a book. The book is called the Mythical Man Mouth, where he describes the concept of people interacting on scale. And the bigger the group is, the harder it is for people to effectively communicate and make decisions. There are similar concepts and I would say that it's credible enough to make our assumptions on this. And it also applies to different spheres of our life. If you will take a look at politics, for example, countries which are like deeply decentralized, they tend to be more effective in managing themselves.

You might ask me, okay, we had five minutes discussions. You convinced us that we should divide it up. Why are we still here? We divided the teams and we gave them full autonomy. So we have different features and they have been worked by people on those features. And you have a small team with two people when somebody wants to use something and the other person is like, yeah, come on, we live only once. Why shouldn't we do this? It's fun. It's going to be cool to put it on our CV. Let's do it. So you're happy and you're having a day off your life. Until you don't. Until you understand that probably you crossed some boundary, which you shouldn't have crossed and you caused some problems which you don't entirely understand yet.

Companies and questions which we are going to be talking about are a local scale up from the Netherlands and still very big, I mean, not very big, but somewhat large software as a service companies. You can get a kind of rough idea of what the size of those companies is and the larger companies they have real CICD and they deploy a lot.

And if you want to deploy like 15 or like, for example, 77 times a day, you cannot test your stuff manually. You have to rely on automatic tests, testing it for you. And the tests take time and the bigger your app is and the more complex the business logic of your app is, the more time it takes to run your tests. And this is not a fictional example of what can it be. And that's not the worst example. And that's a result of continuous multi-year efforts to shrink this number. So it's like many beefy machines spending a lot of electricity somewhere in America running your tests on the pipeline just to fail. So another problem of end-to-end tests is that it's very difficult to make them stable, especially if you run a lot of them in parallel, you actually also create some kind of concurrency and whatever you use as a backend for your end-to-end test needs to be reliable as well. So yeah, imagine that you have to redo this operation often and often, again and again, and it makes your engineers somewhat unhappy.

This is an example of how massive of an improvement you can get from switching to microfrontends. Since every microfrontend can have a test that is dedicated to this specific microfrontend, you can have a good guess of what it takes to test the specific microfrontend. These are the real numbers for us. We went from 45ish minutes on average to 5ish minutes on average, which was a really nice improvement of life. Usually it was building quicker than the developer was writing in the description for the tickets, so we were incredibly happy. Eventually, we had to extend those with a couple of platform-wide end-to-end tests just to make sure that we didn't screw up globally. But besides that, no massive changes were made. If it's not clear what is.

On top of that, we can see that there were additional improvements. In the case of FreshBooks and 3Way 42, it enabled us to use new technology. 3Way was stuck with the first version of Angular. FreshBooks was using Ember. And I'm not sure if anybody still uses Ember here. It's actually a functional framework which is being maintained. So it's not exactly deprecated. Nevertheless, it's difficult to find people who want to do Ember. It's difficult to find modern technologies which support Ember and whatnot. And in the case of FreshBooks and Personio, it enabled us to improve our pipelines, run them faster, reduce the cost of pipelines because we run them faster, and also reduce the amount of single point failures so people wake up less. And of course, people autonomy.

You can make decisions and be somewhat happy about them, to some extent. There are a couple of misconceptions when it comes to micro-frontends. Often people think about this image from Google images request for micro-frontends where you have a tractor and multiple micro-frontends on the same page. I can't recall how many times I've been sent this image. And so you have like menu in Angular, something else in React, and the rest of the page in Vue.js. Whatever you see there is called horizontal split. It's the approach when you have multiple front-end frameworks on the same page. But also, there is another approach which is called vertical split, where you have one micro-frontend up on the screen at a time where you divide your apps by domain.

Since while horizontal split is functional and helpful, I didn't work in the companies which could benefit from it to full extent. And normally, it's e-commerce companies because they can render their micro-fountains on the back-ends. They can ship the resulting bundle as HTML. Since we are building our micro-fountains on the UI, we cannot afford ourselves to have 30 megabytes bundle size. It was important for us to be more reasonable about it.

In both FreshBooks and Persona, we opted to use vertical split micro-fountain architecture. Now, let's talk about challenges. First challenge is defining migration strategy. If you have a large product, you cannot suddenly decide that you have a new thing. You have to restart the previous thing and get three years of development efforts out of somewhere and build the thing. If you are reasonable about that, there is a pattern which is called Strongest Pattern, which basically suggests you to wrap the old thing into Facade framework and start growing the new thing next to it until you finally eliminate the old thing. Be realistic, invest in tooling because chances are that you're going to stuck in step 2 forever, so you need to be comfortable to be in this situation.

Another challenge is dividing domains. Domain-driven design isn't extremely simple topics. There are plenty of books about it. It's a challenge on the back-ends, it's also a challenge on the front-ends, and those challenges aren't necessarily answering the same question. It's okay if your front-end domains are going to be different from your back-end domains. If you opt into vertical split architecture, you're going to have pages which have multiple back-end domains displaying data. Nevertheless, you want it to keep as one single micro-fountain. So it's okay to have differences in domain boundaries. Very small domains might cause you building those multiple micro-fountains together just to test them, because one test is going to go through multiple micro-fountains to check the business flow, which is also not perfect, and large quantity of small domains might lead you to the same problem which we started with, with somebody fixing code which nobody exactly owns.

Third challenge is managing dependencies and pipelines. I hate it so much. It's really difficult, and we did it wrong, entirely wrong. So the intuitive approach to building things is like, okay, I have a shelf for this, I have a shelf for this, and we're going to separate things. Separate npm package for our components, design system, separate package for helpers, until you start putting it together and debugging, and until you want to debug your component inside the app, and then you have the process of, okay, I need to update the component. So you go to the component repository, you build, you change the components, you build the components, you deploy it to artifactory or npm, whatever you use. Then you update the package version in your application, and then you reinstall dependencies, and then you can see how did it work. And if you want to debug some simple CSS, it becomes quite painful. There fortunately are solutions, neither of which we found helpful enough for us and convenient enough for us to use.

So after starting with separate repos, we decided to use npm link, which we didn't like. And we started using sub-repositories, which was already better. It helped us to avoid versioning and make sure that we can do bigger changes, and we can reduce the frustration around different microphones having different versions of the same package. And yeah, finally we just ended up with monorepo in both of the companies. Both companies had very different path to it, but now we use monorepo in both. I cannot recommend you monorepos enough, and if you're interested in them, there is a nice book which is called Software Engineering in Google, and they claim that the whole Google thing, including YouTube and whatnot, is monorepo.

Managing data. The best way to manage data is not manage it at all, but if you get to manage data, you can have different approaches. First, you can initiate some data when you initialize the framework itself. You can render your microphone with some starting data. For example, it can be your authentication token, it can be your translation strings, it can be your object's configuration settings, like what color scheme they are using, what mod. You can pass it once when you instantiate the app, and then you don't care if this data changed.

If you want to exchange data, especially if you're using horizontal split micro-frontends, where you have multiple frontends on the same page and they need to impact each other, then you can use PubSub. Any implementation is going to do. You can use even RxStreams, whatever you like. Just have something to subscribe to and listen from. You can also put some state machine in there. You can wrap Redux into PubSub and publish changes into Redux if you want. All those things do. See what works for you.

Side effects. Something that is very easy to overlook, but also very straightforward. You have your frontend. You put other frontends inside it. Until you understand that inner frontends can leak things in the outer frontends. It can be CSS, it can be JavaScript. You can easily pollute and break the outer frontend until you find effective measures how you can isolate them between each other. There are different approaches. If you're old enough, you can use iframe. You can also use web components, which I personally recommend. It was very helpful for us. Very easy to implement. Very easy to get out from if you dislike how it works. It's a couple of days of work. You can trust people. Or you can use sculpt CSS.

You can use BEM or CSS imports, CSS modules, whatever you can do to sculpt CSS to fix the CSS issues. But doesn't solve JavaScript leakage.

Before we wrap up, a couple of general takeaways. Make sure to build a good example application. Let's be honest with ourselves. People copy-paste code if they can. And if you have a good example of what a good micro-frontend could look like. It's better if people copy-paste your good example than if they copy-paste something that is not exactly good.

Invest in education. If you spend a week teaching people now, you'll save many weeks, maybe a month, in refactoring their code later. Automate the boilerplate. Especially if you don't have the full agreement in your company to move with micro-frontends, it might be some proof of concept. And depending on how other teams perceive the micro-frontends you build. If they like the experience of working with micro-frontends, if the new approach is better than the old approach, they might be having different opinions on if they want to convince their manager to opt into this or not. And if you have a good tooling, a good boilerplating, and their developer experience is good enough, you have better odds of this idea sticking to it.

Lifting restrictions is easy, but making new restrictions is hard. So if you start in the wild west when everything is possible, you will have a much harder time having restrictions later and standardizing your code base. So if you can afford to start in more restricted modes, you'll have a better time. But I also want to acknowledge that it's not always possible. And please take a look at your dependencies. There are so many rabbit holes to jump into. You can have a hundred React applications with a hundred different React versions. If you get into this situation, you cannot share the React bundle between those micro-frontends. You'll have basically a hundred Reacts being loaded for your website. Make sure that you can easily update packages. If there is critical vulnerability and you have outdated versions, different versions of the same package in different repositories, it's going to be painful. So it's technical depth which you need to keep in mind and you need to make sure that you made it easy for yourself in the future to maintain that.

On this note, I want to say thank you. I really appreciate your coming. Thank you and we'll gladly answer your questions.

Firstly, what a deep story to start with. I was getting stressed and I woke up. It was a nightmare. I was somewhat relieved. We'll jump straight in. We've got about seven minutes to answer some questions. Just a reminder, there's a speaker Q&A section near the entrance or those remotely in the timeline. The ones we don't get round to, if you still want to ask them, pop that after this.

Okay, cool. First question is how do you think this approach is viable without using a mono-repo? Absolutely. What would be the implications of not using a mono-repo? I know you said they're very nice. They're nice to work with. In my day job, I work with a mono-repo. How much more difficult is it without? It really depends on how big potential of scale you have in your app because some apps are never supposed to be scaled. If you are building the website for your local community, it's never going to have millions of customers and it's never going to be big. In this use case, you can have as many repositories as you want. On the other hand, Persona started as a multi-repo and eventually found that we have a problem of not knowing how many micro-frontends exactly we have. That we need to put continuous efforts in just discovering the micro-frontends being built. Technical depth became more difficult because you need to update something that is unknown. You cannot update something that you don't know exists. And that makes it quite tricky in general. Definitely possible. You can definitely live with that. The last bit is discoverability. If you want people to take a look into your PRs, it's much more difficult to get eyes across 100 repositories over one repository with 100 micro-frontends.

I think there's quite a few questions in here which stem from this, and it's actually about how does a team work and communicate while building micro-frontends? I think there's a few. We may come to others like it in a moment. This question got a ton of upvotes, thumbs up, plus ones. What point does the complexity outweigh the benefits of micro-frontends? If you have a small new greenfield application, I would say you don't need micro-frontends. I would say it's not points when it starts outweighing.

I think that micro-frontends outweigh the benefits when you start. And eventually, they start having more sense once you move forward. So I would say for big apps, it makes sense. Not really for small ones. Yeah.

I think in my mind, it's almost the inverse question. At what point do micro-frontends become something that is beneficial to your project? Exactly. That's the question. At what point do you think they become useful? At the point you feel pain of not having them. I mean, yes. Yes. Okay.

You know what? Yes. We have so many questions. Oh my God. They're coming in so fast. I've not had any talk with so many questions coming in. This is wonderful. How do you avoid duplication across micro-frontends? Remember I said trust people. So to some extent, it's this. Clearly it's not perfect, and it can be better. We are looking into different means of finding duplicated code, but it's not very straightforward because you can implement the same thing differently. Currently, we have a registry of components built externally, and we are working on socializing it across the organization. So if you build some very domain-specific component, which does not belong to the design system, at least there is a centralized place where you can go and look that this component exists. But yes, the real problem, we have helpers which are duplicated across multiple micro-frontends, and that's just the price you pay, I would say.

This was one of the questions that came in actually while you were answering this question, but just to be explicit, is it therefore recommended to start with this kind of abstracted component library that can then be used by all the micro-frontends? Is that a common approach? It's an approach we've chosen in FreshBooks because we had a head start. So basically we built an example of how it's going to work. I wouldn't say proof of concept, I would say full-fledged MVP. We had a couple of teams which adopted the approach later, and it was pretty good. But in Prestonio, for example, we had different circumstances.

We had demands for the new design system, and we had to move in parallel with other teams who are going to consume that. It really depends on what state your organisation is in, and if you can afford yourself to spend two, three, four months of head start just preparing for... Yeah, it's one of those go-slow-to-go-quick things, and yet not every team has the luxury or the privilege of being able to take that initial hit.

This next question had so many people who were interested. So what micro-frontend tools or setups have worked for you? And which ones, I suppose, did not? It's worth talking about as well. Yeah, I would say that pretty much everything that we considered worked good enough. I can tell what we settled with. We used Module Federation, and it's pretty good. We used NX for monorepo management, which was also good. In FreshBooks, we have tried Module Federation. It didn't justify downsides, which we had in the moment. So we were just building micro-frontends with VIT. We were dividing bundle, like, shared bundle size of files separately, like React and other large chunks, which we used across micro-frontends so it can be shared. And we had 500 lines bash script, which was doing what Module Federation is supposed to do. I just head to the room and go, whoa, that was a large bash script.

I think we have time really quickly for this one, which I was curious about in your talk as well, because you mentioned using PubSub or other techniques to keep micro-frontends in sync. But how do you handle shared state management? We had this in Rayway 42 because we had Angular application communicating with React App living inside of it. And it was very, very easy, actually. We didn't experience much of the overhead around it. We had a global object, which was communicating between Angular services and our React states. It wasn't Redux, so it was kind of full and dataful. And yeah, I would say the problem is more exaggerated than it actually is.

That's a really good perspective, too, because I would assume it's absolutely huge, not being able to share state. But as you've done it a few times at quite large scale, knowing that actually it's not been that much of an issue is a really useful insight. We are out of time. Once again, there's a speaker Q&A section, a speaker Q&A area, which is near the reception.