Micro-Frontend & Me, a love story // Dan Neciu

This talk explores the concept of micro frontends, highlighting their emergence as a solution to modern web development challenges. The speaker discusses the evolution of software architecture, from monolithic applications to microservices, and now to the front end with micro frontends. He explains that the primary motivation for adopting micro frontends is the need for independent deployments by different teams to avoid bottlenecks during development. Various use cases and pain points, such as legacy systems and the need for performant applications, are presented as reasons for transitioning to this architecture. The speaker also addresses the complexities of implementing micro frontends, including maintaining UI consistency and managing dependencies. He shares insights from his podcast interviews with industry experts, underscoring the growing trend of micro frontend adoption in organizations.

Cuz live coding, live coding is one of the most stressful things. Everything that can go wrong will go wrong all the way to the mic stand. Um Yeah, so I have been informed that there is a more coffee and breakfast that has been brought in. So, later during the break y'all can go and like enjoy refreshments. Uh our our next talk is is by Dan and he's

going to be talking about micro front ends. Very exciting stuff, guys. What else can we say? Uh If you have to go toilet and you come back uh uh the the try to like ninja ninja your way back, you know, like be stealthy. Uh cuz the door might be a bit loud. And uh All good? All good. Round of applause for Dan, please. >> [applause] >> I

am here today standing in front of you to talk about a subject very dear to me. And that is birds. Everyone likes birds, right? There are supposed to be over 11,000 bird species on the planet in all kinds of sizes and colors, all incredible all capable of incredible feats. And each bird on its own might seem insignificant, but by and large is a part of a large

ecosystem uh a complex system, if you will. And complex systems are hard. Then why do we as engineers love to make them even more complex? Why do we love complexity? And in the 1960s, we put a man on the moon using computers less powerful than your phone. And the architecture was very simple. You had like just one mainframe, multiple terminals, you type in commands, and the mainframe

processed them and sent the results back. All the data, all the logic, everything stayed in one place. And look at the amount of code you had to write uh just to to do something like that. In the 1990s, the internet happened, the web architecture, browser sends a request to a web server, uh the script runs once, you get a HTML page, send it back, and then it

forgot everything, you do it again. Now, in the 2000, we consolidated everything into a monolithic application, and today Netflix has something like this, thousands of thousands of microservices, small independent services that each handle one job. So, we went from everything in one place running once with no memory to distributed systems across many services. That's the evolution. But, we didn't stop at the back end. As browsers became

more powerful and could handle more logic and state, uh we started moving complexity to the front end. We built single rich application SPAs. Then, we asked ourselves, if we split the back end into microservices, why can't we can't do the same on the front end? So, over 80 years of coding, two main things drove big architecture changes in our code. One was new tech, the internet, the

increase in CPU power, the browser, cloud infrastructure, AI, stuff like that. And the second is scale. Uh more and more people are using what we are building, and because of AI and technology, we are building faster uh and more things than ever. Which in turn led to engineers uh evolving into specialized roles. You know, you have security engineers, devops engineers, and of course front end engineers. And

as front end engineers, we also need to solve complex problems. So, uh we we took a a peek into our neighbor's backyard, the back end developers, and decided we wanted to do the same, to to tackle the complexities that they did. Um and we looked at microservices and thought, okay, we can do that on the front end as well. Now, personally, I didn't like it. I didn't

like uh the microservice architecture, mostly because I was part of some really big large migrations from monolith to micro services, and I saw first hand the issues micro services face. So, to be fair, micro services had have the incredible infrastructure support from all the tools that we have built like Docker, Pub/Sub, Terraform, Kubernetes, infrastructure platforms like AWS, Google Cloud, and they hold the micro services hand, and

still you have so many problems like it was hard to achieve observability in a highly distributed system. It was hard to keep the boundaries of micro services without creating like a distributed monolith application. And it if it was hard for our back end neighbors who were who were who had this incredible infrastructure, I was thinking for us it would be almost impossible to to get it right.

Plus, when micro services first came out, almost everyone was using iframes, if you remember correctly. And for me I started working with iframes in 2010, 2011, and I hated them. They are so really hard to debug when you go into iframes into multiple iframes levels, so you don't even know where you are. You're feeling like it's inception. Or if you're using micro front ends, you things cannot

come out of the micro front ends. You get clipped. If you have a model inside of a micro in inside of an iframe, it get clips it gets clipped at the end of the the iframe. So, for me I was a big no, I don't want to use iframe. I don't want to build micro front ends. But, just because I didn't believe in something doesn't mean it

wasn't happening around all of us. And the biggest discovery came about as the same time in 2020 as micro front ends became super popular, which is around birds. And the the the theory that came out was that birds aren't real. So, in reality, they have gone extinct, and what we see around us in cities are actually drones by the government to spy on people. Think about it.

Have you ever seen a baby pigeon? So, I started thinking, if birds are real and tech has evolved so far as to impersonate 11,000 species of birds just to be used as surveillance, maybe micro are real, too. So, last year I started a podcast called Seniors at Scale, where I talk about with senior engineers, staff principal levels, book authors, library creators, people like Igor Minar, Luca Mezzalira,

and other amazing guests that I had so far. And feel free to check it out. I have 20 episodes, 20 more are coming up. Um but, what I noticed in my discussion is that almost everyone I was talking to, from companies like N26, New Relic, Buffer, Preply, Data Dog, and so on, almost all of them were using micro front ends in one way or another. And almost

all of them built initially their tool in-house around 2015-16. Uh and when the episode with Igor and Natalia became my most watched episode about micro front ends, I knew I was up to something. So, I started asking more questions in all my interviews to see, okay, why uh why have you built micro front ends? What was the the need for it? And I discovered that all of

them had one single pain point. All of these companies, they they had many benefits for micro front ends, but one really big uh pain point. And that was they needed each team to deploy their work independently. That was it. Of course, there are multiple benefits, but this was the main pain point for companies to invest in this infrastructure. And I felt it, too. In my small startup,

we were only 10 engineers uh who were doing full stack, React and Go, and at least once a month there were CICD pipeline uh that blocked the the code, and people could not release because of another person that that introduced the bug. So, this got me thinking. Maybe, just maybe, birds aren't actually real. Maybe the reason you see birds perched on top of uh power lines is

because they're charging themselves. That makes sense. Power lines are supposed to be filled with like with electricity, and yet these birds and pigeons just stay there minding their own business. But, because these are problems, it led me to see what other problems people had to introduce micro frontends, and what problems micro frontends have on their own. So, if you see any of these problems, micro frontends might

be the solutions for you. So, of course, number one, we discussed about it. Each team needs to deploy independently. So, if someone blocks the pipeline for a given reason, you don't want 40 other teams to be blocked as well. If someone has to revert, you don't want to revert the entire project. Uh if your marketing team wants to deploy five times a day, and your payments team

wants to deploy once a month, uh you don't want them blocking each other or force them in the same release cadence. Uh and if you're a globally distributed team, uh you have uh teams spread across across the world, uh you don't want someone to wait for a pull review a code review from Singapore, but the team is in Barcelona, and there's a different time zone. So, you

want everyone to deploy The second problem is legacy system. Like, imagine you're building an e-commerce platform in 2010, it's highly successful, but you've chosen Angular 1 as your framework. It's impossible to hire now Angular 1 developers. There are no upgrade options. You cannot upgrade to Angular 2 without a a few full rewrite, and the project is no longer maintained or supported for security updates. Uh so, your

app is used at scale, and you have complex features, so you cannot rewrite it. So, you start piece by piece. You rewrite the checkout in a micro front end and deploy it inside of the Angular 1 shell. You rewrite the cart in a micro front end. You rewrite your blog in a micro front end. And bit by bit and piece by piece uh until your Angular 1

framework is just a shell application that ties everything together. And then you kill it for uh JS only app. This normally takes years to do, but I've seen it done firsthand, and I heard a lot of success stories about doing this pattern using Uh another problem that requires micro front ends is if you're acquiring another company. If you're acquiring another company and you want to use their

product inside of your app. Maybe they use a different tech stack than you. Rewriting everything and integrating anything is hard. So, just having a micro front end and plugging it into your product is a better solution. And finally, you can have different performance needs. If your home page needs to be static SEO optimized, and your admin side has megabyte of megabytes of third-party libraries, you might want

to split them into uh micro front ends just for performance optimizations. Of course, frameworks like Next, Astro handle this also, so you might not need micro front ends, but still. Uh so, I know after all of these problems, all of you have one questions on your mind, which is if birds aren't real, what about bird poop? Because it's literally everywhere. On cars, sidewalks, tables. They poop on

Well, think about it. How convenient is that it's everywhere, especially on people and cars? So convenient that the government can actually use it to track you while you're moving across the country. This is a joke. >> [laughter] >> So, micro front-ends also have their own problems. You need consistent and powerful way to handle routing. You need to maintain UI consistency, which is a struggle when you're using

multiple repos. You need a powerful tool to observe the system, and you need to share state between micro front-ends, which is not easy to do. And many more issues, but let's start building our micro front-ends. So, let's say you identify that you need micro front-ends in your project, and you're starting a new project, or you're starting a new project from scratch. I would recommend if you're starting

a new project from scratch, don't even think about micro front-ends. You need a really big and powerful infrastructure for them. And micro front-ends and microservices as well are more successful when you break them out of a monolithic application. Again, the the main problem is the number of people and allowing them to build, scale, and deploy. So, if you have a team of four five people building micro

front-ends from scratch and duplicating, having boilerplate everywhere, it will just slow you down. Create frustrations. So, the way to do it is breaking a monolithic application into micro front-ends. So, start normal, break it down when the system is stable, features are set in stone, and teams need to be scaled. That's the the main reason to start on So, how do we split them? Well, Luca Mezzalira, when

he was principal and architect at DAZN, DAZN is like the Netflix app for sports, he found a clever clear way to separate them. He followed the user's journey. So, during user session, they look at Google Analytics, and they saw, "Okay, 100% of people that came on the landing page, 40% drop off. the other 60% went through the signing process, then 20% went to the catalog, and then

another 5% watch something. So, he separated micro front ends into the landing page micro front end, the onboarding experience, the catalog experience, FAQ and help, and then my account. So, this approach mirrored how users actually move through the app. Um and aligned well with domain-driven uh principles that they were using in the So, when he did this, he realized there are actually two architectures for micro front

ends. The vertical micro front ends, uh where each route is its own micro front end. So, for example, you go on one page, you click on a nav bar, this boots up one micro front end, you go on another page, this boots up another micro front end. Or horizontal um architecture micro front ends, where on the same page, you can have multiple micro front ends. Think you

have a dashboard, three charts here, each it's its own micro front end. Now, each pattern has its own use cases, strengths, and problems. Um the the vertical micro front end is the easiest to build, uh and the most familiar to developers. and like Luca, you can split it by user journey. Now, typically a SaaS app like Datadog or New Relic, each menu item represents its own micro

front end. And when your app is structured this way, and your organization is structured this way, it's only normal to first load lazy load each module in your app, and for everything else, when you click on uh an item, you go to the next But to to make micro vertical micro front ends work, you need to keep the shell application, the app that loads uh as simple

and as framework as agnostic as possible. If possible, it should be just an empty empty HTML page with basic logic for cookie management and just the the navigation. Why is that? One of the technical complexities of micro front-ends is sharing state between micro front-ends. And it will be a a really big mistake for everything to manage the global state in the application shell because then every time

you need to to make a change, you have to change code in the application shell and that makes the application shell basically a a common a common ownership base for every team, which you don't want. You want the the shell to be owned by the infrastructure team and that's it. then you the main routing is also decided in the shell application, but you can even make it

better by having the the routing application on the cloud level on the load balancer and engine x level. So, where you go to a URL, the the engine x and load balancers knows which micro front-ends to load and generates the HTML edge side. Again, this is the easiest way to build micro front-ends and the most recommended way um once your team and products have begun to scale.

The horizontal way, uh this means on the same screen you can have the multiple micro front-ends. Uh for example, in an e-commerce application, one team owns the product detail side, another team owns the product carousel. But there are a couple of complexities with this approach. First, the routing gets a little complicated. Um so, it's not recommended to have like second level roots. Um most of these micro

front-ends need to communicate with each other, so communication is tough to handle. There is a bigger need to share state and the boundaries between micro front-ends are harder to define. So, it's easier to over over-engineer and create micro frontends when a web component or an NPM package would suffice. You also need a bigger investor investment in infrastructure when you're orchestrating um your micro frontends like this. And

of course, there's also dependencies management. You don't want You want micro frontend has React, the other micro frontend has a different version of React. You don't want the uh shell application or the user to have to download two versions of React. So, you have to take that into account. Luckily, there are a couple of frameworks out there that can help you with this. Module Federation is a

popular one. Then you have like web frag- fragments by Igor, uh single SPA, Pyral, uh which has a different approach on how you load and offload micro frontends. Zephyr Cloud, who's a sponsor here today, has a way to orchestrate micro frontends at scale. Um Nestor is giving a nice talk later today. Check it out. Uh and you can see how most of these stack up and which

one you want to use on my podcast where I talk with the authors of them. Uh and the big advantage of these micro frontends and their technology, uh the frameworks, is the plug-and-play functionality they provide. Uh they give you the infrastructure so you don't have to think about it. So, given all these questions, how would you build them? So, the most important thing is you need to

keep the shell framework agnostic and as simple as possible. Uh usually owned by the infrastructure team. Uh a typical anti-pattern would be changing the shell project very often. Uh even the menu items or loading or unloading the micro- micro frontends could be backend driven. So, you'll make an API call, the backend gives you the entire navigation, and which navigation item opens which um micro frontend. So, or

you handle it on the edge like I mentioned earlier. Uh another anti-pattern would be having global state in the shell. Each micro front-end should have its own state and communicate with other micro front-ends easy either you by using a bridge, back-end for front-end gateway, or by implementing a common communication channel. The easiest way to share state is to use the query params in the URL like using

the URL as as a state management. But this should be reserved for very simple or critical states like user tokens or whatever. Another way to achieve this is by using the broadcasting API, which is like a native web browser API that you can communicate between tabs. But the most common way is by emitting events, creating like a an event bus, and event emitters, and each micro front-end

listens to the event that it's interested in, and you can also go a step further and create like a brain micro front-end that facilitates communication, allowing you to register events and subscriptions. Now to solve the UI issues, a component library and design system is almost required. Typically, you extract this into an NPM package and install it into each micro front-ends. And you have model federation to handle

dependency CSS should be encapsulated using shadow DOM, CSS module, or using like an atomic CSS library like Tailwind because you want to avoid first CSS duplication, but also also so your CSS rules don't override other CSS rules. Like if you declare a button into one micro front-end and a button in the other micro front-end, you don't want to have this mix. Obviously, you can go wild and

each team can choose their own tech stack. Some micro front-ends on view, others on react, and then the shell just mix and matches them. You can do this, but I won't recommend this approach. It's a slippery slope. Plus, it adds extra complexity for the infra team to maintain multiple pipelines. So, I will take advantage of really good framework functionalities like Next.js, Astro, Nuxt because they have become

super performant and can make integrating micro front end in a mono repo application quite easy. Uh, so finally, you have to keep it simple uh route at the client level so you don't use page refreshes every time you click. Use React Query with the same key so you can easily reuse API responses. Follow the DDD domain driven design practices and avoid falling into everything should be a

micro front end practice. Uh, if you you if you think if the main reason you want to create a micro front end is reusability, you're thinking, "Oh, I'm going to reuse this part in somewhere else." Maybe that doesn't need to be a micro front end. It could be a library or an NPM package or a web component. Um, try to if you're building horizontal micro front ends,

start with vertical first and then as you scale, split it those verticals into multiple horizontal micro front ends. Um, and of course, if you are a very small team, like a two-pizza team, you're five, six people maybe micro front ends are not needed. And the most important part and the message that I want to convey is to focus on pain. Uh, see which part of your software

is causing the pain and whether you need uh to do your own research to solve it. Just because someone is on stage telling you that birds aren't real, don't listen to him, right? Uh, check what works for you. Everyone has different context. Uh, and the the birds aren't real is actually a true conspiracy theory that someone started as a joke. Um, but people started believing in it

as people do. Yeah, of course. Of course it is. >> Um So, also going into micro front-end architecture is a one-door decision. Once you take it, it's very hard to switch back. And choosing a micro front-end framework also creates a significant vendor lock-in. So, it's very hard to switch vendors once you start. Uh so, really take this into account. Finally, here are some resources that I heavily

recommend. Building micro front-ends by Luca Mezzalira, The Art of Micro Front-ends, Learning Domain-Driven Design by Vlad. I also have three episodes out on Seniors at Scale podcast that talk just about micro front-ends. And my own newsletter about architecture, system design. I share takeaways from my podcast, so I think if you're interested. I also give out discounts for conferences.