Microfrontends: Heuristics, Patterns and Antipatterns by Luca Mezzalira

Transcript

Olimpiu Pop: Hello, everybody, I’m Olimpiu Pop, and I have in front of me Luca Mezzalira, one of the forefathers of micro-frontends. Without any further ado, Luca, please give us an introduction of yourself.

Luca Mezzalira: Yes. Hi, everyone and thank you very much for having me in this episode of In InfoQ Podcasts. I’m very excited about sharing a few things around micro-frontends. My name is Luca Mezzalira. I’m a serverless specialist solution architect working for AWS at the moment, and over the past 10 years, I started to rationalize how micro-frontends or better distributed systems for frontends are working and how they should be implemented. Hence, I have delivered several talks worldwide. I’ve written a couple of editions of the Building Micro-Frontends book and tried to contribute as much as possible to the community with let’s say some specific patterns that we have implemented over the last few years, like the discovery pattern and many others.

Olimpiu Pop: Thank you, Luca. Looking at your presentation, it was like a nice aha moment. I have to admit I’m a backend guy, and one of the benefits of generative AI is that I can finally have something that looks decent. Well, it’s probably full of holes and everything, but for now, it looks great. You wrote the micro-frontend books quite some time ago, and now you’re writing your second book. What changed in the meantime? How did the ecosystem mature? Tell us your take on this period?

Microservices, microfrontends, data meshes and team topologies are interconnected [01:49]

Luca Mezzalira: Absolutely. The first edition was released at the end of 2021, early 2022 basically, and I started to write it in 2019. That is at least co-located with the findings. At the beginning, when I started 10 years ago, there wasn’t documentation or let’s say many examples that would lead me to define an architecture. I basically took the microservices’ implementation that was very well explained by different people like Sam Newman, Neal Ford, or many others, and I started to apply the principles behind to the frontend and adapted obviously for the frontend part because it’s different from the backend. Right? Since then, when I wrote the first edition, only a few companies had adopted this approach.

A few of them are pretty well known, like back in the days there was Microsoft, there was PayPal, there was Zalando that is a fashion e-commerce, Fever and many others that tried to do the first implementation of micro-frontends, but the community was relatively immature mainly because it was a new topic. Up to that point we always worked building monolithic frontend applications despite we had microservices on the backend.

During my time at DAZN, which is a live sports streaming platform, I basically mastered this idea of micro-frontends and trying to create a vocabulary around that, creating patterns and identify anti-patterns that were basically the culprit of our development. In fact, we use micro-frontends across our applications, and we work on different devices, not only web applications. Since then, to be honest, I moved to AWS, and I was able to help hundreds of teams worldwide from New Zealand to Silicon Valley migrating towards micro-frontends. What I have discovered during this year, and that’s also the reason why I wanted to write a second edition of the book, was that many of the patterns and anti-patterns that I have gathered during the previous years were common across multiple companies. But then I started to refine them and started to see commonalities across different industries, project that I follow from B2B to e-commerce, retailers, stuff like that.

I started to realize that there was more and provide more heuristics for people to embrace properly this approach because everything boils down to identify the role of platform engineering. For instance, at the beginning was more let’s say loose to a certain extent in the first edition because I tried to cover the things that I believe were important like automation pipeline, how to think about that, deployment, et cetera. But I think in this new edition I cover way more with way more opinion, and plus, the ecosystem changed drastically.

In fact, Vercel, Astro and many other well-known frameworks nowadays are starting to wire towards the micro-frontends approach. I remember React. With React 17, they embraced the idea of the possibility to have multiple React version inside the same virtual dome. That is interesting because at the beginning they were reluctant to do that. Nowadays it is normal having React available into… Having micro-frontends with React available. There was a lack of tools at the beginning in 2021.

Nowadays, we have plenty of tools that enables people to build micro-frontends properly. Recently there was let’s say a new version of Module Federation and single-SPA that are two or the main frameworks I would say for building micro-frontends on the client-side rendering. For server-side rendering, we had Vercel that did a huge investment in the last year and a half building micro-frontends as a first-class primitive inside their platform, and also democratize several of the challenges that we have experienced in micro-frontends to their customers. Not only that, I think the direction of travel is getting more interesting with these acknowledgement that there is a strong need of distributed system on frontend.

Funny enough, to be honest with you, another thing that I noticed in the architecture space that makes me extremely happy is that after the let’s say announcement or the introduction of microservices back in the early 2000, more or less at the same time when I was starting to talk about micro-frontends globally, also data mesh came along.

There was a need for different layers of a system to be distributed because we realized that with distributed teams, we can achieve more and work in parallel. If we design properly our system, we can work independently.

This is something that I witnessed firsthand with several of the AWS customers as well as with let’s say companies that have followed where teams started to be independent despite that we are cross-functional component aligned, and I think is a testimony of the good job that the micro-frontends community have done over the years where we started to be more present in different conferences, inspire people, provide documentation, provide examples, simplify the development and the developer experience specifically for developers obstructing certain concepts that before where let’s say custom for each implementation and nowadays became a commodity that they think is something that we have experienced a lot also in the cloud, if you think about that.

Olimpiu Pop: Nice. Let me try to put that in a nutshell. During this period of let’s say four to five years since the first edition of the book came across, the ecosystem matured. We don’t have to speak only about the micro-frontends per se because they are part of a bigger picture, and the whole distributed mindset moved probably… Let’s say that it grew more from that perspective because we don’t have only microservices, we don’t have only micro-frontends, but we’re discussing about data mesh. The concept of distribution in software architecture is becoming more interconnected with the way how we build also teams. That means that distribution and autonomy are the points moving forward from that perspective. Would that sum up what will be the message?

Luca Mezzalira: Yes. That’s absolutely correct. I think it’s important to realize that if you remember, we are old enough to remember the time when, I don’t know, a small team of three, four, five people, you can build a end-to-end the system. That might not be the most advanced one, but I remember building e-commerce with two, three people, or I don’t know, software inside embedded devices with a couple of people. I think that time has changed because their requests from our customers and consumers are completely different. Also, the complexity around all the different aspect that compose a software has changed. Therefore, we need to have multiple people working in the same social technical system.

In order to do that, we cannot use the approaches that we were making, we were using in the past with the monolithic end-to-end system. We need the level of modularity and granularity that has to be expressed across the system in order to make our teams let’s say moving fast towards the release process.

Do you really need a microfrontend? [08:58]

Olimpiu Pop: Thank you. I have to say that even though I saw multiple presentations, also the recordings from QCon, yours remained in a nice place. The main reason for that is that you found a way to speak the hands-on approach, even though looking, at points, at higher level concepts. The heuristics were probably the nicest thing that people would like to because it’s people are using analogies, and now you’re putting in place these nice things, the best tools for developers. But we all know that usually we don’t get a green field, most of us don’t even receive a brown field. Then I was thinking how should we as developers, as architects, whatever, as technical people look at our application with a critical eye and see if we are in a good place or not? How would you suggest we should be looking at that? What would be a checklist? A heuristic to do that?

Luca Mezzalira: First and foremost, I would start by asking: “Do you really need a micro-front end?” Sometimes I’ve seen very often trends coming in, especially in the frontend community, and people jump into these trends straight away without asking themselves if it’s needed, because the moment that you move towards a distributed system is an entirely different situation for several layers or dimensions inside the company to take into account. That’s the first thing that I would assess.

Usually, everything boils down to the number of people that are working on the same project, or if you are working on a multi-tenancy system where a part of the system is entirely standard, if you think about the signing-up of a project, and then you have a part of customization. Therefore, even with small teams of fewer than 20 people, you can reap some benefits from micro-frontends, in my opinion. That is probably the first thing that I will look at.

In case you decide that micro-frontends are the way to go, then we need to look into how to slice the monolithic system. There are a couple of recommendations that I usually provide when we are talking about that. First and foremost, many people and many teams and companies ask me if we need to have microservices to work with my frontends? But in reality, not in my experience, because at the end of the day we are consuming an API. Right? The API, it doesn’t really matter for the frontend if it’s coming from a single API gateway or multiple API gateways, microservices, there is monolith… It doesn’t really matter. The contract is what really matters. You want to use GraphQL because currently you have GraphQL, go for it. You want to use REST, go for it.

One data point that is interesting in my experience over the last few years is that every time that a company starts to look into modernizing through microservices and micro-frontends, the migration or modernization towards micro-frontends takes between a third or a half of the time compared to microservices.

If not even more sometimes because if you think about that data has gravity. Therefore, we don’t have on the micro-content side to think about, okay, so we need to take this massive table or this database, humongous database, and split it in smaller and decide if it’s SQL, NoSQL, a graph database, vector, whatever. In frontend is by far easier starting with, and then you can cascade that decision towards the backend or work in parallel, depends from the capacity of a company.

The other interesting thing that I noticed, so if we say we need just an API that at the beginning could be even what you have right now without massive changes, maybe there are some tweaks that are needed but nothing too crazy, you can start to work on the frontend side and usually my recommendation is starting from a more coarse grain approach. I created this mental model called the decision framework where I say that the first thing that you need to understand is identifying micro-frontends.

Slicing the monolith into microfrontends [12:47]

Either you can have a single micro-frontend that is loaded per time, that is a representation of a single view or multiple views, or it could be multiple micro-frontend at the same time. Majority of the time companies are starting with a vertical split, so having one single micro-frontend loaded because it’s easy to resonate. It’s easier to assign and find boundaries. The real challenge is only finding data points that enables you to say, “Okay, we are going to slice in this way.” My recommendation in this situation is to usually try to understand how your users are using your application. When I started, for instance in my previous company to rationalize how we could slice the application in micro-frontends, I identified the certain patterns that were happening inside the application.

I also described them in the book like, “Imagine that you have a million requests coming to the landing page, but then it was a drop between the landing page and the sign-in and sign-up experience. If you were an authenticated user, you didn’t pass through the landing page or the sign-in or sign-up page; you just went straight into the live video streaming catalogue.” That was fantastic because, in micro-frontends, you typically load an application shell first, which can determine whether the user is logged in or not.

This logic is very generic and can then redirect the user to the right page. Either check if there is a deep link, ensuring the user can access that specific area of the website, or if the user is already authenticated, simply refresh the token and verify that they can access an authenticated area. This approach is pretty interesting. Once we have understood how to split the application, the first step is to know how to route towards a micro-frontend application.

Now, people are afraid to start a modernization because they might think Now I need to go to the management, ask for 24 months for rewriting everything with the latest version of the frontend framework. Then slowly but steadily building everything while I need to keep the lights on, adding new feature in the monolith, and then migrate finally on the other side. But with micro-frontends, because we are splitting up the system in different chunks, it becomes easier to do the migration also and also generate value for your customer and business. Let me give you a concrete example.

Imagine that you understand that one of the key elements of your system is the catalog of your application. The catalog of an e-commerce, that everyone has at least one experience with an e-commerce. Let’s assume that in this e-commerce you have a variety of categories, and you can have furniture, and then you have toys and other stuff. Right? You don’t have to go all in and say, “Okay. We need to recreate an entire catalog, and then deploy and see if it works.” You can take a subset of the system.

You can start very easily with one small category that could be toys maybe and build the application for that and create a micro-frontend for that, and then leverage the URL for entering that specific endpoint to let’s say maintain at the beginning the old catalog alongside or the old application alongside with the new micro-frontend one.

Then understand what works, what doesn’t, if there are issues you can roll back very quickly because at the end of the day it’s just a DNS change that you need to redirect towards, again, back to the monolith. This approach, combined with the vertical split where you have one single view group of views deployed together, enables you to have results and understand how the system works end-to-end very quickly. Because the reality in the distributed system now you don’t have anymore a team that maybe thinks about the CIs, D1s and forget about that. Now you have a constant iteration through that.

You always help people to understand how the observability works, that maybe they didn’t spend too much time while micro-frontends is extremely important because you need to understand what’s going on in production when problems arise. At the same time, you need also to know what the development experience looks like because now it’s different. Right? You have way less to build, way less tests to think about, but at the same time you need to have touching points with other teams that before you didn’t have, how to update dependency and stuff like that. I think though this concern will be let’s say addressed during this iterative approach that we are going to take because we are taking one path at a time if you want.

Slowly but steadily, I’ve seen many customers implementing with these recommendation, their micro-frontends approach, and they were using for the routing part a bit of compute on the edge in wherever CDN they were using. Nowadays, every CDN I can think of, they have a bit of compute that can be leveraged on the edge. This is great because if you start writing the routing logic on the edge, it means you don’t have to pollute the code of the micro-frontend or the monolith. That means less to change and less to test. This is the only entry point that you have, and the vast majority of time nowadays, every single web application, whether server-side or client-side rendering, is front-faced with the content delivery network.

Therefore, it became pretty easy to approach in this way without polluting the code that you’re going to have. This is something that worked at scale with several companies, adding a lot of value, because you don’t want to go all in with a 24-month project without having any benefit immediately.

This is also used with some companies for migrating from an older version of the framework to another version of the framework because the nature of slicing iteratively your application without the need of ending up with a micro-frontend could be very helpful. Because if I move from, I don’t know, a old version of Angular to a new version of Angular, I can take one chunk, one URL or endpoint, and then slowly but steadily adding more stuff in the new Angular application that is monolith or micro-frontend, it doesn’t really matter. But I had customers that have done both successfully, and I think this approach should become more ingrained into the frontend community because very often I take inspiration and patterns from the backend. Those are stuff that we were doing for what? I don’t know. 20 years more or less. The frontend is still new, and sometimes it’s a struggle to make people understanding that those can be easily implemented without too much burden.

How architecture, metrics and organization structure interconnect [19:21]

Olimpiu Pop: Thank you. Usually, when discussing frontend, one of the things discussed was how heterogeneous the ecosystem was. Since we started our conversation, at least two or four new frontend frameworks have emerged in the meantime, either in .js or .ts format, and that was happening quite quickly. As you said, people were embracing them blindly at points. Then, as you touched on, a couple of points are obviously in the backend and have more visibility. Nowadays, I’m thinking about Sam Newman’s presentation, and when you say it’s okay, how do you choose the proper retry mechanism? Or the number of retries that you want to have? What’s the timeout? What can we learn when we’re discussing micro-frontends? As you mentioned, you’re talking about how your customer behaves? What kind of tangible metrics can we use, and how can we implement them.

Observability is essential these days. What can we implement immediately? That will help us move the discussion with more visibility.

Luca Mezzalira: Indeed, we need to tackle this question in two areas. One is how we will split micro-frontends. Two dimensions have to be taken into account. The first one, as I mentioned before, is how your project is being used. Because sometimes we think that, and I’ve seen that a few times, that the user is doing the thing in a certain way, and this may be some assumption that product managers have, while in reality, they’re using your tool differently. That’s the first thing to consider. The second one is how your organisation is structured, because we are all familiar with Conway’s Law. Therefore, we know that we need to design an architecture that enables our organization structure to move and to deliver what is needed.

Sometimes, you can design the architecture first and then rearrange the organisational structure to enable the architecture to shine. Sometimes you cannot, and therefore you need to create an architecture that mirrors what you have currently inside the trenches. It is a crucial point that is often underestimated because architecture, organizational structure, and engineering culture are three dimensions that are tightly coupled. Whether you like it or not, you can intentionally or accidentally touch one of those dimensions, and that will affect you badly or positively based on your decision. If you do it obviously accidentally, it’s a high risk that any decision would generate friction inside your organization because it’s not seen as a social-technical system but more like a technical system. That is a big problem, in my opinion.

On the other hand, when it comes to observability, several tools can help you understand how things are working. Think about, for instance, Sentry, LogRockets or even NewRelic. Nowadays, a majority of the observability tools used for backend APIs also offer solutions for the frontend. There, you can understand that logs are necessary. Still, Core Web Vitals is another key metric that we care about on the frontend to understand, especially for server-side rendering, how the application functions, whether it adheres to proper standards, and so on. But first and foremost, the key thing is understanding logs and the volume of traffic, obviously into your system, to determine what to cache and what not to cache.

All these things should be set up at the beginning of the first deployment of micro-frontends because those are definitely some key elements that compose a micro-frontends architecture. If you think about it, not having them in a microservices system means you’re blind, because when a problem arises, you don’t know where to look. You just have hunches. But specific tools enable them to plug themselves into the state management of a frontend application.

Then, when the problem arises, they are capable of replaying the different steps that the user passes through to trigger that specific problem. If you think that a simple mechanism like this can cut the time required to fix a bug from hours to maybe minutes or from days to hours, then just let’s say it can. As you can understand, those tools are incredible nowadays. All of them are suffering at the moment, or at least I’m not aware of any that are adequately designed for a distributed system.

What to test in the inner loop [23:37]

You need to work alongside your provider in order to get let’s say their approach for that. But I can tell that back in the days, we were able to make Sentry work with the distributed system, and we were talking about 2016, 2017. I presume that nowadays we need some improvements. I’ve seen companies leveraging more and more, but I believe this is definitely one other dimension that you need to invest in. The last one on metrics that I think is extremely important is on the automation part or the shift left movement, as I used to call it, where we also need to enforce specific characteristics in our system. One thing that is important when you are looking at a monolith is the budget size or the size of your artefact. Now you don’t have a single artefact anymore, you have multiple of them. Therefore, people often struggle with that.

But there are some good things that you can leverage. What you can do is, I don’t know, plug some of these characteristics into Git hooks. Before, I don’t know, making a PR or let’s say committing some code, you can build on the fly the micro-frontend, understand if the budget size is respected, and assign even a threshold of leverage for discrepancy in the micro-frontend size. That will enable you to apply certain characteristics that very often people don’t think at all. Because as architects, we want to have certain capabilities expressed inside our system, but the majority of the time without fitness functions where only let’s say guesses or dreams that we wanted to have. Nowadays, we can test certain things. I was doing recently a test with the TSArch library that basically is a porting of ArchUnit from Java. The idea of this is that you can enforce certain criteria.

I can write a test and say, “This micro-frontend can have only an external dependency that is the shared library or this design system, wherever it is.” I can test that the micro-frontend doesn’t retrieve other, let’s say, libraries, external libraries from it. As you can see, there are three dimensions that we need to consider regarding the data points we need to gather in the micro-frontends world. One is on how to slice micro-frontends, so how does the user behave? A second one is during the CI/CD cycle in the automation part, so expressing our architecture characteristics properly as well as providing certain guardrails to the team in order to behave properly.

Finally, when the system is up and running, so when the system is in production and we want to understand where the bug or the issue is arising from. Those three dimensions are obviously completely new, to a certain extent, compared to the monolith. I think those are sometimes the struggles that people either don’t think about at the beginning or overlook.

How to offer a consistent experience across multiple device types [26:21]

Olimpiu Pop: Well, listening to you, a naive question from the backend mind came. As mentioned, I started with the disclosure that I’m a backend guy, so I’m stepping into new territory. I was just thinking that we are quite lucky on the backend side because the servers are in your house, let’s say, whether it’s in a public cloud or in your data centre, you pretty much know what you’re expecting. You can tweak. While discussing the front end, you’re looking for a very heterogeneous environment, as a significant percentage, I don’t remember the exact number, but I know that it is well above 50% of the traffic is coming from the mobile world. It’s very complex, and then we’re looking at different browsers, different screen sizes, and so on. How do you handle all that complexity? The problem is that on the frontend, everybody’s an expert; everybody knows how big a button should be, how it should behave, and everything else. That’s scary from my perspective.

Luca Mezzalira: Yes. I think providing an experience that is common across multiple devices is becoming the standard even for startups to be honest. I’ve seen a lot of startups that are currently offering web and mobile and sometimes even other devices. I think micro-frontends can help on that because even on mobile, people might not know, but there are solutions like React Native, with Re.Pack that is a library created by Netlify that enables you to use Webpack with React Native. That means that Module Federation can be a first-class citizen inside your system. The beauty of this approach is that you can think about a mobile application as a group of views, like you would for a website.

If you’re using React end-to-end from website to mobile, you can have a very interesting experience and potentially even thinking about have some part shared inside the specific vertical. Ideally not across the entire application like we were used to do in the past, but if I’m responsible as a team of the UI part of a chunk of the system on web and mobile, better is likely that you can share certain part of the things. But then obviously if you have multiple teams working independently, you need to think slightly different. But that’s something that we need to take into account. Now, for the UI part, I think it’s important to leverage web standards in this case. If you think about the design system, if you need to start from scratch, having web components definitely will help you to achieve your goal better because are compatible with any framework.

Therefore, you don’t have to reinvest time every time that you change the framework for moving towards one direction or another one. I think very often we think that micro-frontends can be a very scary approach because it will impact the performance. In reality, if you think about that because you are lazy loading at runtime only the code needed for apply an action inside our system from our users. Now you discover very quickly that there are some great benefits in performance thanks to micro-frontends. Just to give you an example, the vast majority of time in e-commerce or any subscription services that require a payment method, you have to integrate with multiple payment systems. You have maybe the SDK of Stripe, the SDK of PayPal and many others.

I work in this system was global, therefore I have a lot of SDKs to integrate. Thanks to micro-frontend because we were lazy loading only what was needed, we were capable to load this SDK only when a user was signing up and they reach the payment method or if the user wanted to change the payment method. However, suppose you consider that in a monolith, you need to have them immediately, specifically on the web. In that case, it means that it will load your memory with a lot of stuff that won’t be used for majority of the time despite definitely we require a lot of more thoughts compared to let’s say monolith, I believe that can provide incredible benefit, mobile web, et cetera. If you play well on your side, you can even think to share particular part of the application across devices without too much burden, to be honest.

Continuous deployment strategies to avoid “big-bang” impact [30:27]

Olimpiu Pop: Nice. The other thing you mentioned, continuous deployment, is also related to continuous integration. Well, with continuous integration more or less it’s clear. Well, clearer. You just have your test, they are continuously running. You have your fitness functions and all the tooling that are ensuring you that everything is happening. But then I’m just thinking that with continuous deployment I would aim to have a gradual deployment, not go all in. All these kind of mechanisms, but how would you look at that from the micro-frontends? Is it more like would you like to have, I know I’m just saying now, a canary deploy where you’re just looking at part of your fleet or of your ecosystem, or you’re doing A/B testing or both?

Luca Mezzalira: Yes. That’s absolutely valid question that I receive very often when a company became more mature on the micro-frontend side. Because now you have multiple independent artifacts, you can leverage canary release and blue-green deployment like you would do for microservices. That is a practice as it consolidated over the last decade, I would say, or slightly more. Everyone is using that. On the frontend side we are still working with Big Bang. Don’t ask me why because that was the first thing that I implemented when I was working in my previous company because I think it is a safe net for developers. Right? The moment that I can say, “I want to deploy my micro-frontend just to, I don’t know, 5% of my traffic, just in a specific browser and just in a specific country,” then developers can test in production without affecting massively their system.

Now, I think there is a place for canary release and blue-green deployment as well as for feature flags in micro-frontends. The challenge with feature flags that currently people are using a monolith is that in the monolith you have your code base all in front of you. Right? You have control of everything. But in this case you are responsible only on a portion of the system, and therefore, I think now you need to combine the two in order to have the best of both worlds. By default you don’t have feature flags every single time.

If you have a feature flag that’s spun across the entire system, it becomes very complicated for micro-frontends. It’s better that you rethink your strategy because now you move a different piece. Otherwise, you’d need to coordinate massive teams that are not independent anymore, that sometimes it’s needed. I’m not saying no, but it’s not always the thing. You need to try to figure out the best way to use both.

In my opinion, I tend to use more with micro-frontends, canary releases or blue-green deployment and have just specific things that they use for feature flags. This approach honestly helped me a lot to de-risk the deployment of our system. In 2022 I worked with a group of people and maintainers of micro-frontends frameworks like Zach Jackson and Joy Dunning and Matteo Figus where we created basically a schema for doing canary release and blue-green deployment, and then they started to apply inside the frameworks. Nowadays Piral or Module Federation 2.0 and et cetera have a system for doing exactly this, so have a mechanism for doing that. Even in AWS working with Matteo, we created an open-source solution that you can deploy in AWS very quickly that enables you to notify through your CI/CD when there is a new micro-frontends version and decide how you want to deploy.

This is been because, if think about that is what we call in AWS undifferentiating heavy lifting. Now, once that you have created that there is no need to reinvent the wheel. I’ve seen a lot of teams that started to create integration inside the browser through plugins or a crazy JSON configuration for doing that. That’s not really needed. I think there are better ways to do that. Yes, there will be a place where you want to rewrite the URL of specific things. I know that there are solution that there are upcoming from the major vendors, but in reality I believe that you need to start simple. Don’t overcomplicate the process. Let’s start with the bare minimum, and then you start to add up slowly but steadily. I usually think about this system like leaving systems. It’s not something that you design once and you forget about that. You need to nurture them. You need to work and slowly by steadily implement a tiny bit more to make your life easier or better or more performant or whatever is the metric that you want to move.

This approach for me is the right way for thinking about that. Software is not set in stone. It’s something that you can evolve, and the only thing that we need to embrace in software is changing. Therefore, if you start from this mindset and you know that you can do a tiny bit better every sprint, then you probably arrive to have a very let’s say complex maybe safe net that will enable you to have multiple dimensions that you can tweak, but slowly but steadily. You don’t have to go in one go, and then ask for the business, “We need to invest six months for building that.” Do a first bid. Do the things that are bare minimum, and then you start to iterate on top of that. You will discover that very often you are overthinking at the beginning. When you start to have let’s say more data points that prove the direction of travel is correct, you will be in a better position to justify the investment to the business.

Olimpiu Pop: Thank you. That’s quite insightful. But now that you opened another door, another question. Let’s say that we do have the 24 months. I know we both know, everybody knows it’ll not be the case, but we do have the chance of rebuilding everything from scratch. What would be the point? How should we look at it? What will be the let’s say milestones? We need to start with that part, that will be the other point, so that we don’t think in terms of feature flags but let’s say milestones that are business-wise that makes sense but also from the technical perspective.

Luca Mezzalira: Okay. How I would tackle is, A, identify the first micro-frontend. Okay? It shouldn’t be something too complicated but not even something that let’s say is too easy. You need to find a sweet spot that in matter of a month or two you are in production. Then I will divide the effort into one is rebuilding whatever framework, if you want to change framework or extracting the code from the existing application from a part of the team.

Then the rest of the team should look into how routing works. That will enable you to have a simple micro-frontend that is extracted from the main application, taking care about the authentication authorization, stuff like that. I will also create with an additional group of people or team the application shell, whatever is server-side or client-side rendering. When you have one micro-frontend, an application shell that is loading just that micro-frontend, don’t create crazy complex logic for doing that, at runtime obviously loaded.

Then you have a way for redirecting traffic between monolith and micro-frontends application, you are in a good position to start with. Obviously at the beginning you need to find a way to either have time to create observability straight away or have a fast follow-up on that. You have a chunk of a system that you can operate maybe not in the best way possible because I didn’t speak about canary release or anything else. I’m just saying do the first step, and do it right and doing fast so you can learn from it. From that point on, the work streams start to be more interesting. I will start to wait a bit before immediately start with the new micro-frontend to gather information. What is working? What is not working? What we are missing? What is something that you would like to have immediately?

Then start to divide and conquer what part of the team will look into these missing parts of things that could make your life easier. Another part of the team will start to look into the next micro-frontend. If you start to take all these things iteratively, you will discover that slowly but steadily some stuff will arise. I remember vividly when we introduced let’s say the routing on the edge and then we started to say, “Okay. But if we have this, we can do canary release,” and we started to apply that. The first release was just the routing, then we did canary release.

Then we did other stuff like we realized that the developers need to have the possibility to tweak the application shell in a certain way to test their things. Therefore, we started to create a blueprint where for developers that they can have the latest version of the application shell with the JSON that was loaded at runtime baked into the application shell.

You can tweak it in the way that you want and start to iterate in the way that you want. Then from that we start to look into the CI/CD fitness function and how to improve the performance of our application. Slowly but steadily we add all pieces that are needed, but if you start with we need to analyze everything before starting, you end up with an analysis paralysis that basically will fail miserably for moving forward. The main point I believe in this system because enables you to iteratively deploy a small chunk of improvement every time is moving. It’s important that we move towards the right direction. Yes. It would be a bumpy journey because sometimes you make an assumption but the result of your data that you gather after deploying is not maybe exactly what you’re thinking about.

I believe it’s fine because that’s the point is we are working on an empirical system. Software is not scientific, it’s empirical. Therefore, we need to work with trial and error. Errors it’s just part of the journey. It’s not a negative thing how many people thinks about. It’s just I need to do an error, so I test my assumption. The assumption was wrong, and I gather error to tell me how I can tweak these next tests in order to move towards the direction. I think this is the approach that will take, and I’ve seen several companies successfully implemented that after the discussion we had. Then we tweak the direction of travel based on their findings.

Where to find more inspiration [39:57]

Olimpiu Pop: Thank you. You mentioned before. In the beginning you mentioned now companies that are having approaches. For the microservices world there was Netflix. For a long period of time Netflix was the bible for everything. In case of micro-frontends, are there any companies that have good public content in the technical blogs that are worth being looked at, used as inspiration?

Luca Mezzalira: There are a lot of case studies if you look into Medium from engineering blogs that are available there sometimes are in Dev.to if I remember well. There are let’s say a pocket of stories that you can find. Because I know that people are avid consumer of content, I started to do quite a lot of stuff around that because I believe that micro-frontends very often are betrayed mainly because people don’t… That maybe had a bad experience or didn’t have enough capacity for building them properly.

I started to create a few things, like I have a video podcast that’s called the Micro-Frontends in the Trenches, that is available on Spotify, Apple Podcasts and YouTube, where I basically interview people that are building micro-frontends or framework maintainers or a company like Vercel in the previous season. There I’m basically trying to surface these stories because I know some of them, but people maybe don’t have the time or the will to write down their learnings.

I’m a huge fan of community and sharing these things, so I started that, alongside also a micro-frontends newsletter that basically is a free resource that every other week I share free for information regarding micro-frontends that I believe is useful I started from scratch last year. Now there are over 3,500 people subscribe. It means that there is a community behind that that wants to know more and more. I’m trying to push hard on creating content for micro-frontends.

If you look even on YouTube, you can find tons of talks about micro-frontends that I delivered but also other people have delivered because the community of let’s say key people working on micro-frontends is not huge. We’re talking about I would say a dozen of people, 20 top. But nowadays, it became contagious. When you have a company like Vercel that I would say is probably at the forefront of frontend companies nowadays that is starting to embrace micro-frontends, and they already have micro-frontends in their website and other things and their customers as well, I think is huge.

AWS is the same. If I see how many companies I spoke with in the last even 18 months, I don’t know, the number of companies migrating to micro-frontends is doubling. It is crazy because it means that we are starting to reach maturity, and people start to see the value out of it. I think it’s a super exciting moment for micro-frontends, especially now with also the AI part that could help on the migration. I did some trials on helping company to migrate certain views from one framework, an old framework to a modern framework. You can cut the time of building views very quickly. Therefore, I believe there is no better time than now to think about migrating towards the system if the architecture makes sense for your context.

Olimpiu Pop: Okay. Thank you. A lot of very useful insights. Thank you for that. Is there anything else that I should have asked you what I missed?

Luca Mezzalira: No. I think it was a very interesting discussion on key points, and I believe micro-frontends are becoming more popular as we speak. I hope that these discussion will help other people to give a chance if they didn’t try it yet.

For other people that already practitioners, they might find some gems of information that could be helpful. The only thing I’m more than keen to offer to everyone that wants to have say some information about micro-frontends, feel free to ping me on social because as I said, I’m a big community fan. You will see on my social that I’m trying to answer everyone, obviously compatible with my time, but I truly believe in this sharing approach because I think it’s the way how I grow as engineer first and then now as a architect. I truly hope that many other people will be able to reach other people out there because there aren’t too many people that have 10 years of experience on micro-frontends and led the path on a discovery of these things. I’m extremely keen to help others nowadays if you have specific questions.

Olimpiu Pop: Thank you. Okay. Thank you, everybody. We had Luca Mezzalira sharing his knowledge about micro-frontends. If you want to get more of that, he has a YouTube channel, he has a newsletter. He’s working on a book that probably last quarter if I remember correctly it will be available.

Luca Mezzalira: It will be available at the end of November.

Olimpiu Pop: Okay. It’s a good present for Christmas if you want to give yourself something. Thank you for your time, Luca.

Luca Mezzalira: Thank you for your time, and I hope that was insightful.

Olimpiu Pop: Thank you.