#47 - Micro-Frontends and the Socio-Technical Aspect - Luca Mezzalira

Episode Introduction [00:00:56]

Henry Suryawirawan: [00:00:56] Hello, this is Henry. It’s great to be back here again with another new episode of the Tech Lead Journal podcast. Thanks for spending your time with me today listening to this episode. If you haven’t, please subscribe to Tech Lead Journal on your favorite podcast apps and also follow our social media channels on LinkedIn, Twitter, and Instagram. You can also make some contribution to the show and support the creation of this podcast by subscribing as a patron at techleadjournal.dev/patron, and help me to continue producing great content every week.

For today’s episode, I am happy to share my conversation with Luca Mezzalira. Luca is a principal architect at AWS, an expert on micro-frontends, and the author of the upcoming “Building Micro-Frontends” book. Today’s applications have become increasingly complex and often built by a combination of multiple teams working together, in order to deliver the best user experience for customers. While microservices has become a popular architecture of choice at the backend services, micro-frontends also has started to offer similar benefits that can be applied when building complex front ends or web applications.

In this episode, Luca described the concept of micro-frontends in depth, along with the where and when companies should apply this concept for building the frontends, as well as sharing how he successfully implemented micro-frontends at DAZN. He also shared about the important principles behind micro-frontends, why it is important to be technology agnostic when building your micro-frontends, and how to design the CI/CD pipelines to stitch the different micro-frontends together and deliver it as a one unified product.

Luca also mentioned some of the common pitfalls and anti-patterns that we should avoid when using micro-frontends, as well as sharing his tips on how organizations can start adopting micro-frontends in their architecture.

I enjoyed learning micro-frontends from Luca. And I hope you will enjoy this episode as well. Consider helping the show by leaving it a rating review or comment on your podcast app, or leave us some comments on our social media channels. Those reviews and comments are one of the best ways to help me get this podcast to reach more listeners, and hopefully they can also benefit from all the contents in this podcast.

So let’s get this episode started right after our sponsor message.

Introduction [00:03:51]

Henry Suryawirawan: [00:03:51] Hey, everyone. Welcome back to another new episode of the Tech Lead Journal. Today I have another awesome guest for us to have a conversation. His name is Luca Mezzalira. He is actually an expert in micro-frontends. So for some of you who are into building UI/UX front-end technologies, this is an episode that you don’t want to miss. Luca is very expert in micro-frontends since I think a long time ago, maybe let’s clarify later with him. He’s been working at DAZN, helping them to transform their platform into a global streaming platform. And now he’s working at AWS, Amazon Web Services, as Principal Architect. So welcome Luca to the show. Good to have you here and hope to have a great conversation about micro-frontends

Luca Mezzalira: [00:04:35] Hey, Henry, thank you for having me. It’s a pleasure being here and I’m very excited to have this episode with you.

Career Journey [00:04:41]

Henry Suryawirawan: [00:04:41] So Luca, maybe in the beginning, can you help to introduce yourself? Maybe telling us about your highlights or turning points in your career.

Luca Mezzalira: [00:04:48] Yeah, absolutely. So, I started working in IT when I was 21. I’m a self-taught person, so no university, no studying. I learned the old school way. So coding every night, every day, Sundays, Saturdays. There wasn’t a time where I stopped. I started with the Flash platform back in the days in 2004. And there, I had a lot of success to be honest because the platform was great and allowed me to unleash my creativity. I worked mainly outside the browser. So mobile devices, embedded devices. I worked even on a motorbike with creating like a dashboard and digital dashboard instead of the mechanical one, and it was quite fun to be honest.

But after 10 years living in Italy where I’m coming from, I decided to move to UK. First of all, as a lead developer in a startup called VideoScribe, and basically we were doing a software for creating these kind of videos where you have like hand that is writing and mimicking the real person that is drawing. After few months I was called in London and then moved as a senior developer in a gambling company. After few months, I became tech leader. There, I changed the way how they used to work with developing software because we were used to develop gambling game one every nine months, and when I left, we moved from nine to three months of delivery time. There were hundreds of people in my department. We were doing 80% of the revenue. It was quite fun and very engaging. It was quite an interesting project for me because it wasn’t touching only the tech part, but also the people’s side.

After that, I moved to an agency called Massive Interactive that was specialized on OTT platform or a streaming platform. I became extremely passionate about that because I understood that the industry was in the middle of a revolution, and it was extremely interesting developing on a console, smart TVs and set-top boxes. I had the opportunity to have my hands dirty in the code for a few set-top boxes. It was extremely challenging, but I have to say extremely rewarding as well. There, I followed a project for a company called DAZN where then I transitioned to them. Basically in 6 years, we moved from not having a brand and not having a reputation to having a global distribution in over 200 countries. And I think that was one of the key highlights of my career. Because I had the possibility to take the project basically day one as the inception, worked closely with the product team, and created a platform that raises a lot of success worldwide. I was able to travel around the world. I was in Japanese launch. I was in the Italian launch. I followed basically all the key turning points of the company, and I was slowly but steadily, growing personally, and also my careerwise. Because I became, at the end, vice-president of architecture there. And then after six years, I thought that was the time to see if this knowledge could be helpful for other companies. So then I moved to AWS as Principal Architect.

Henry Suryawirawan: [00:07:41] So Luca, what made you decided to go into micro-frontends because hearing what you say just now about your career, it seems like a lot of variety things that you did, there is an early sign for you working in like digital dashboard and things like that. But you move on into architecture, global streaming platform, and things like that. What made you decide to go into micro-frontends

Luca Mezzalira: [00:08:01] Yeah, that’s a good question. So back in the days, almost five years ago, we had a challenge. We just released DAZN platform in a few countries – Germany, Austria, Switzerland, and Japan. We had a massive growth. We moved from hundreds to thousands of people in a year and a half more or less. Obviously, we wanted to develop our solution and have a certain flexibility and agility meanwhile we were developing. And the team was distributed across Europe. So one challenge that I had to face was thinking how to move from a monolithic code base on the frontend and backend to a distributed system that would allow the team to work at their own speed and reduce the communication overhead across teams. Obviously on the backend, we have consolidated patterns like microservices. But on the frontend, we didn’t have much, to be honest with you.

So what I have done, I started this journey on identifying what are the principles for making a successful distributed system architecture. And I took the principle of microservices, and I try slowly but steadily to apply it on the frontend. Because the reality was, I couldn’t have tens of developers working on the same code base and coordinate across multiple offices. Also with the pandemic, that situation could be even worse because you start to have people working (in) different time zones. So what we have done basically, taking those principles behind microservices applied to the micro-frontends, and came up with a bunch of principles that were our north star, and start to slice our application using a bit of domain-driven design, and looking at how our users were interacting with the platform. And based on those information, we sit down with the small team that we had back in the days, looking at the platform, identify a bunch of bounded contexts that could be splitted (into) the platform. And then suddenly we realized that it could be extended end-to-end, at the frontend, but as well on the backend.

That was an extremely interesting journey because as you can imagine, 5, 6 years ago, there weren’t guidelines on how to do that. For us, we had to reason, find the right way for approaching this challenge. It turned out that in less than a month, we were able to have a POC up and running and working on web and few TV devices. Performances were pretty good. Obviously, back in the days we had to figure out the right way to do this because we could end up very easily to have an override of creating a lot of tools for streamlining the developer experience. So one of the mantras that we had is trying to keep our implementation as agnostic and close to vanilla JavaScript as possible. That doesn’t mean we couldn’t use frameworks or anything, but we were smart enough back in the days to try to simplify the creation of our micro-frontends, and compose them all together using paradigms that are already available, like using HTML DOM for stitching everything together, leveraging a solution like appending asynchronous JavaScript file on the DOM, and automatically the browser was taking care about loading and parsing and everything. So we try to be as simple as possible in order to achieve our goal and split up the development of our teams.

Micro-frontends [00:11:11]

Henry Suryawirawan: [00:11:11] So maybe for people who are mostly familiar with microservices, could you maybe describe what does it mean to have a micro-frontends architecture?

Luca Mezzalira: [00:11:21] Yeah. So, usually when you take all microservices, you start to look at your subdomain. So you take complex platform and you divide them in smaller problems. For instance, let’s take Netflix that probably everyone knows. You’re thinking Netflix, obviously you don’t just watch some content. You have like customer support. You have a possibility to change subscription type. You can pay with PayPal or credit card, and all these parts contribute to the final platform, to the final domain. Obviously, you cannot take all that in one go. You need to start to slice those boundaries, and divide them in subdomains. And then inside the subdomains you have what is called bounded context, where you identify some areas that can be tackled in isolation. The same thing happened on the frontend.

So if you look at the frontend side, imagine like the Netflix website. What you usually do as a new user, you go to the landing page. Then if you like the offering you go to the sign-up journey. And then during the sign up flow, when you finish that, you go to the catalog and you start to watch content. So just with this three, you can easily identify potentially three different user flows. The first one is for the users that are going to Netflix, and trying to understand what the service is, and maybe they stop there. And maybe they don’t care because it’s not fulfilling what they are looking for, and therefore they stop there. Second step is signing up. Usually you have one part for your personal data and you share your email address, first name and last name, and then a second part for your subscription type and payment. So those things, for instance, can be bundled together because if I’m a user, what I’m doing is first understanding if I like the offering. If I like the offering, I move forward. But when I have done this, and I’m convinced about subscribing, I’m authenticated user, it’s unlikely that I’m going to the landing page or to the sign-up page. The reasoning behind that is trying to create some context, and some experiences, if you want for the users that will allow the user to download the code only for that specific experience. Obviously, if he wants to download more, hey, at least you can do that. But that’s the initial idea. Obviously later on, we discovered that you can even go more granular. So there are situations where for large organization especially, you start to have micro-frontends in the same view. Because in reality, there are situations where you have multiple teams or you have a micro-frontend can be re-usable across multiple views. So in both cases, having micro-frontends that are smaller, fine-grain compared to a more larger grain, a solution is definitely a possibility. So at the end, the micro-frontends are what they call a representation of a business subdomain, and we should differentiate them from components because components are solving technical problems. So I want to reuse this specific functionality in multiple places of my code base. But micro-frontends is that you’re looking from the product side. You start to look at how you can create value. You can generate value in isolation for your users. And that’s basically where we stand at the moment with micro-frontends

Where to Apply Micro-frontends [00:14:18]

Henry Suryawirawan: [00:14:19] So in terms of applicability to technology, is it only for web based frontend? Can you also apply it to a mobile devices, native, hybrid?

Luca Mezzalira: [00:14:27] Yeah, so it’s an architecture, so therefore it’s not bounded to a specific technology. We applied on web and TV devices, not all of them, but some of them. They are for living room devices and the outcome was positive. On mobile, we didn’t because we were working with native technologies, and back in the days we didn’t spend too much time on revamping that because the application was running very well, therefore we didn’t need to review that part. I would say yes, it’s applicable on mobile. So if you’re using React Native or other solution, yes, you can definitely think about this. The only challenge that you have on mobile, that’s a discussion I had with quite few people, is that the nature of web usually is that you are online by design. So if you want to consume a website, you need to be online. On mobile, you need to think also on the offline experience. So if you start with an empty package, if you want, and you have an empty application and slowly but steadily you are composing everything. That could be an idea.

But if you think about creating a smooth user experience, potentially you need also to think on downloading these micro-frontends and storing inside the device. Or maybe having just a bare minimum set that will allow the user to have a decent offline experience. And then you have, let’s say, something more to think about. I think it’s totally doable. But at the same time, you have more to think about because obviously the nature of the experience there is offline and online. And sometimes offline first. Personally, I’m quite annoyed when I play games that you can only play online, because maybe you are doing commute and you are in the tube in London, and you don’t have a connection for any given reason. Therefore, I want to play my favorite game, I cannot. So we need to think also about this stuff. It’s not just showing a nice page saying, oh, please connect to the internet because sometimes we can’t.

Team Structure [00:16:08]

Henry Suryawirawan: [00:16:09] So if I hear about the history just now when you mentioned the work that you did with micro-frontend you are actually taking some of the principles from the microservices, which has been around for longer than micro-frontends so now that you have these both microservice and micro-frontends how does it work? Do they actually vertically share the same teams, same groups? Or are they also still split between frontend and backend?

Luca Mezzalira: [00:16:32] So there are different schools of thought. I personally think you can do both, and I explain why. One way to handle the team communications usually is through API contracts. API basically allows you to define a contract between two or multiple parties. As long as you respect the contract, everyone can work in isolation, and can work in parallel. So therefore, in our case that we add multiple devices, mobile, web, living room, we decided to have teams that were working on your frontend and only on backend. Because otherwise, if you think about cross-functional teams, we ended up to have 15 people just on the development side without taking care about QAs and everything, because the variety of languages and everything that we were working on wouldn’t allow us to have a smaller team. So we’ve studied, we’ve divided these by domain by target. This could help us to achieve what we wanted to do. The way how we tackle that without having a first class citizen in one of the frontend, because potentially we could say we have the backend developers together with the web developers, and we can create a cross-functional team. But in reality, web became the first-class citizen because all the APIs would be designed and adopt for that. But in reality, we want to have a fair way to handle a cross platform application.

So you can work in both ways, and I think APIs are the key, using techniques like backend for frontend, or using GraphQL would allow you to decouple the two teams. So if you are working with component teams, as they’re called in Agile, or cross-functional teams. Either way, you can work with both. Also, I want to extend this concept. We mentioned that, for instance, you want to migrate your frontend to micro-frontend but you need to remain with a monolithic code base on the backend. You can do it the same way as long that you work with API contracts. Because at the end of the day, there is a nice separation between frontend and backend. The APIs are creating these loose coupled worlds between the two. When we start to have a very tightly coupled world is where I start to be worried because then the evolution of either part could be compromised.

When to Consider Micro-frontends [00:18:34]

Henry Suryawirawan: [00:18:34] Speaking about different teams, different companies these days, right? They are all in different situations. Some are still working on monolith, either backend and frontend. Some are using single-page application, backend for frontend, and different devices, and all that. When should we actually start thinking about micro-frontends? Is there a turning point in a particular situation within the team, or maybe challenges in terms of traffic, or a situation about the company that we should start thinking about micro-frontends?

Luca Mezzalira: [00:19:02] Yeah, absolutely. Let’s start answering with one thing that I truly believe, micro-frontends are not a silver bullet. I’m not here advocating that we should migrate every workload to micro-frontends because that definitely is not suitable for many companies. I think there are some turning points where, for instance, you have large organizations with many teams that are working on the same code base, and you want to create independent teams that could work at their own pace. That is definitely the best case for micro-frontends. Another situation that I have seen micro-frontends working well is with multi-tier applications where for instance, you are offering a SaaS service and you want to have multiple modules. You create similar infrastructure for all your customers. But at the end, you always have a part that you need to modularise. So therefore you can say, let’s assume you have 10 micro-frontends, 9 of them remain the same, and one can be customizable for a specific customer. That is another theme that I have discovered alongside this journey.

I have the fortune to interview and speak with people all over the world that are embracing this technique. That’s also why I’m spending a lot of time advocating that. In reality, to be honest with you, I think in architecture, you always find a trade-off, there aren’t best practices, because best practices are based on the context. And if you don’t understand the context, you cannot replicate the best practice, because it could work very well in one company, but not in another. Therefore, in my opinion, micro-frontends are a very interesting approach that should work alongside Single-Page Application, Jamstack, or server side rendering applications. It should be used with caution, because obviously it’s providing us with some pitfalls. You start to create multiple CI/CD pipelines, you need to have a strong observability, a strategy behind that. So all the things that we have seen with microservices are also true for micro-frontends, because the reality of the things is you have similar things. You have distributed systems that have similar problems and similar benefits as well. Therefore, as long as your benefits in your specific contexts are overcoming the drawbacks, definitely is a good approach.

But sometimes, I saw people that currently are taking this wave of micro-frontends, and just using it in smaller project, and they’re creating, in my opinion, lot of overhead for nothing. Because the reality, they won’t be able to leverage the benefits provided by micro-frontends. Because obviously the small team can achieve independence and modularity, also with just good code practices, cause encapsulation, everything that we have learned in the past with design patterns, and can be applicable easily also with two or three teams working together in the same code base. Micro-frontends are moving that to the next level, especially when you have distributed teams, we want to reduce communication overhead across teams, and you want to create independent teams. But obviously, this has to be reflected also in the organizational structure. So at the moment, if you are using microservices and micro-frontends, you need also to de-centralize the decision-making.

So the domain experts, now, the developers should take certain decisions, and making certain calls inside certain boundaries. And the boundaries usually are defined by the tech leadership, by the platform team, or architects, principal, and so on. Instead of dictating things, in my opinion, they should enable the teams to do their job properly, and they create the boundaries where they should operate because they have a decent knowledge of the big feature. Obviously, the other activity that those people should do is facing patterns that are happening inside the team. So for instance, if a specific team is solving a problem, and that the architect or the tech leader, the principal knows that another team is facing similar problems, maybe taking that pattern, creating the opportunity for sharing, and see if they can reuse the same approach. It definitely could be a new activity that these kinds of people should do, because they should own the big picture, and allow the team to make their own decision. I truly believed the DevOps model where you build it, you own it, you run it, is the right way when you embrace distributed systems, because otherwise you create external bottlenecks that are basically frustrating the team, and not allowing the company to get the main benefits of these architectures.

Examples of Apps Using Micro-frontends [00:23:01]

Henry Suryawirawan: [00:23:01] You mentioned that you have met a lot of people who try to implement this micro-frontends. Apart from DAZN who has done it properly, what are some of the maybe famous applications or systems around the world that are actually embracing micro-frontends?

Luca Mezzalira: [00:23:15] Yeah, sure. Publicly I can tell you there are quite few companies that came out with that. So IKEA is the first one that are using Edge Side Include. Zalando is another one that is a fashion e-commerce, and they did two implementations of micro-frontends and open source the first one, that frameworks called Tailor JS. PayPal recently published quite a few posts around that. So if you’re a user of PayPal, definitely you’re using micro-frontends architecture. Same for American Express, they release an open source framework all across that is doing that. Other companies like Skyscanner is using them, OpenTable. To a certain extent also the Amazon marketplace, if you see that the code, how it is divided inside inspecting the website. You can see there are some approaches similar to micro-frontends therefore, at the moment many large organization has implemented that. But also, the smaller ones were looking for decentralization of their organization, empowering the teams. Because in reality, those principles that we discussed so far are also affecting the engineering culture and the organizational structure. Usually architecture goes hand in hand with that. We cannot forget about Conway’s Law. Therefore, we need to always bear in mind that our decisions are not just technical, but also affect the organization and the communication flow between teams.

Micro-frontends Principles [00:24:33]

Henry Suryawirawan: [00:24:34] Speaking about principles and you mentioned early in the conversation that actually you borrow some of the microservice principles. Maybe for some people who are not familiar with microservice and best practices, what are some of the principles that you took from microservices that are also good to implement in micro-frontends?

Luca Mezzalira: [00:24:50] Yeah. So using Domain-Driven Design for understanding the bounded context of your micro-frontends. That is one. The de-centralization concept is another strong one where empowering the team, first of all. Then another interesting one, in my opinion is a culture of automation where microservices, especially nowadays, with the rise of serverless, our business logic became reduced drastically, the cognitive load because are way smaller, the microservices that we are building, but at the same time, you start to have arrays instead on the operational side. So you need to create infrastructure as code. You need to create observability, monitoring, logging, tracing, and all the other stuff that goes around. So the same thing is happening with micro-frontends. The moment that you embrace a distributed system, you are going towards that.

But I think micro-frontends are pretty new. If before we had the Single Page Application, for instance, we had a binary situation where either your code is downloaded, or it’s not loaded, then the only thing that could fail is the backend. Now especially on mobile websites, you can have part of your application that is loaded and another part that is not. And then I think in this case, we need to handle those situations gracefully. We cannot honestly think about showing a 404 page, because the user didn’t download all the interface. So we need to think about that. We need to also test these things because the reality is it’s not enough just to rely on frameworks. We need to have solid testing strategies that would allow us to make sure that when something happened to our application, everything would work anyway. And that’s basically a few of the principles that I put together when I was working that.

The other thing is trying to be as technology agnostic as possible, because the moment that you have a very opinionated way, especially when you share code across micro-frontends, you may risk that you are cornering yourself in an angle that would be complicated to get away, and will require a lot of effort, and maybe refactoring around the code. Therefore, being mindful of what you are sharing, what you are not sharing. And sometimes thinking that duplication is not evil, sometimes could accelerate your team, and add some speed. Because handling dependencies or shared dependencies across teams, it means that you are creating external dependency for the team, and maintaining that in the long run with tens of teams, it may be not trivial. So sometimes, a bit of duplication doesn’t hurt. Obviously, I’m not saying here that we should duplicate everything. But there are situations where you need to be pragmatic and see that the duplication is not going to affect the final result too much.

Technology Agnostic Micro-frontends [00:27:21]

Henry Suryawirawan: [00:27:21] Speaking about technology agnostic, I’m not very familiar with all this micro-frontends technology. So, if you allow me asking some basic fundamental question. These days, take example, web technologies, people are using either like Vue JS, React JS and all that. So when you say about technology agnostic, do you mean that we should not base our micro-frontend architecture, using fundamental frameworks like that? Or is it something different?

Luca Mezzalira: [00:27:44] It’s a slightly different point of view. So, definitely you can use those frameworks. It’s very important obviously for speeding up the development, and it helps you to achieve your goals. When I talk about technology agnostic is when you have a key point of your architecture, trying to help the team basically to don’t close themselves in a specific route, and don’t have a very opinionated way. Just to give you an example, you mentioned that one of the main challenge when you deal with micro-frontends is creating a UI consistency. Design system definitely feed inside the microservice, micro-frontends world. Now for that, what I recommend more often than not is using web components, because web components are technology agnostic. You can use them either that if you’re using Vue JS or Angular or whatever is not a problem at all. Yes, maybe it’s an effort or for learning, if you’re not familiar with them. But in reality, in the long run, you are creating a design system that can be reused in the future, despite the turning point that the company will have, and the business will have.

Therefore, if today you have Angular and tomorrow, you are moving to a newer version of Angular or another framework, you won’t have any problem because you can reuse the design system. I would say without it, that could be different in the case that you start to have a design system for Vue, because you are using Vue, and then you move to another framework, a new different version of Vue and we require you to change everything. That definitely would be an additional effort that you want to do. When we did DAZN, for instance, one thing that we did was how to load every micro-frontend inside this thing called application shell, that basically is the initial point where you have for the entire user session. This application shell, what it does is parsing an HTML page, and appending the nodes that are related to a micro-frontend inside. As you can see here, we’re not using anything that was dedicated to React or Vue or Angular, we’re using web standards because we didn’t want to preclude ourselves in the future from changing technology or anything. So as long as you got a framework that is outputting HTML and JavaScript and potentially CSS, it’s going to work. It’s not going to create any issue. So, that’s the point where I think we need to be mindful, and try to be technology agnostic. There are other stuff that obviously doesn’t make any sense, it’s true. It’s fine with using a specific framework, especially when you’re creating some views or other stuff. But for these kinds of things, I believe it’s kind of important that when you stitch the things together, and you share code, try to be as agnostic as possible, and sometimes you won’t be able to do that, because the context doesn’t allow you to do that. And that’s fine because it’s trade-off. You optimize for your context. You’re not optimizing for the whole world.

Application Shell Concept [00:30:19]

Henry Suryawirawan: [00:30:19] Speaking about the app shell, I’m very interested in this concept because it’s like a container at the end of the day, right? It’s like a starting point where the view will be stitched together. And I imagine that if you have a lot of micro-frontends, maybe let’s say you have a user information, and you have shopping cart information, and all that. All these different HTML fragments can be generated using different libraries, different dependencies, maybe different frameworks internally. How do you ensure that the app shell actually can make sure that everyone can work together, without having some clash or some kind of a broken dependencies, and things like that?

Luca Mezzalira: [00:30:51] Yeah, that’s a good point. So currently there are frameworks that help you. The latest frameworks are helping you to achieve that. For instance, I’m now thinking Module Federation with webpack that literally this week was announced also would be implemented also in ESbuild. So it would be not only webpack that is available, a lighter version of roll-up, so it’s getting a lot of traction, and is solving exactly this problem. So you can use the Technology you want. They take care about wrapping the scope of your dependencies. You can even share dependencies inside your system, and everything is nicely handled by the Module Federation plugin that is available in webpack, but in the future in other building systems. That is at least one way. In our case, it was more coordination because obviously as you said, we have HTML fragments and we load one micro-frontend per time, so we don’t have clashes between teams for sure. If we have to do that, you have different ways to do this.

For instance, I know SAP is using a framework called Luigi framework that is based on iframes, and then you wrap everything on an iframes. I know that many people could start to scream because I said the magic word iframe. They say most effective sandbox that we got are web browser. So, I know that maybe it’s not great to use that for certain use cases, but if you think about the use cases of software, you’re an enterprise environment, you are a B2B system, not B2C. Extracting data from some can be nontrivial, so having a decent interface framework that handles with one or two iframes in the view, the final outcome for the users is probably less than a problem. Also, they can control the environment where they work is not consumer environment. So overall, I think it could be a natural choice for handling potential memory leaks, and for handling strong boundaries between micro-frontends. There is currently TC39. There is a proposal for one thing called realms. Basically would be a lighter iframes if you want, where the iframe is copying the entire DOM object with window. Realm would be lighter, but it’s creating a sandbox of whatever content is there. Obviously still in second draft, so there is still a long time before we see them in JavaScript, if they come. But the idea sounds very appealing and that could be a good fit for micro-frontends. Meanwhile, I would say Module Federation is a place where I would recommend to look at mainly because if you’re familiar with webpack, the developer experience became extremely familiar, and simple for any developer to start with.

There are other frameworks like single-spa, another great framework in my opinion, that solves similar problems in different ways, and you can also mix and match with Module Federation. But in general I would say try to understand your context of what kind of problems you are solving before you pick a framework. Because it’s not as simple as saying, oh, I pick React to begin and I become a fan of it. But let’s try to understand what kind of problems you are solving, and how it’s going to impact in your context.

Micro-frontends CI/CD [00:33:42]

Henry Suryawirawan: [00:33:42] Speaking about building a system that has micro-frontends, I’m speaking in terms of Continuous Delivery, Continuous Integration, how do you actually assemble this build and deployment pipelines? Do you actually create multiple artifacts for different micro-frontends, and then you have another pipeline that actually stitches them together? How does it work, actually?

Luca Mezzalira: [00:34:01] Yeah. So, usually what you do is create multiple pipelines, one per micro-frontend, and then the stitching depends which composition you decide to have on micro-frontends. You can have a server side composition, you can have an edge side composition, or you can have a client side composition. In the case of the client side composition, we have the application shell that is basically lazy loading the different micro-frontends. Usually, you have a container that is loaded and knows how to display the micro-frontends inside it. An example is Module Federation, it’s like that or single-spa are doing this.

For edge side composition, there is a language called Edge Side Include, was released several years ago by a bunch of companies, including Akamai and Oracle that created this markup language, ESI. What it does is basically leveraging the transclusion concept, where you have placeholder that is replaced by a micro-frontend at the edge. In this case, it’s happening everything at the CDN. So, great for static content. You can also use NGINX and Varnish. The problem that you have in all of these approaches is that the ESI markup language is not supported everywhere with the full specification, therefore Akamai is the only one that is allowing to do that. And when you have dynamic content, you need to supplement these with client side include that basically is the same concept of transclusion but it’s happening on the client side. The developer experience is so so, and you cannot definitely afford multi-CDN strategy with that.

On the server side is that you basically have some potential templates that you maybe host, and you fill with data and then use server-side rendering everything on the client, or you can use what is called isomorphic universal architecture, where you are basically having some code that is running on server and on the client for dynamic content, for instance. And you can mix and match certain of those options. In my opinion, it really depends what you need to achieve. If you want to have strong SEO, probably you’re going with the server-side rendering approach. And there are, for instance, some interesting twist there. I know that also Next JS is looking into Module Federation, and it’s pretty big because it means that we are basically starting to get even more traction with micro-frontends, and the moment that you see ecosystem like webpack and so on. It means that really, we were able to show the benefit that this approach could take. Now the difficult part is understanding where the boundaries are, in my opinion, but it would be fun to see the next few years.

Micro-frontends Anti-patterns [00:36:22]

Henry Suryawirawan: [00:36:22] Speaking about implementing it correctly, so what are some common challenges or anti-patterns or pitfalls that you have seen from the practice worldwide? Because you have spoken with many people.

Luca Mezzalira: [00:36:33] Yeah. Many developers when they have multiple micro-frontends in the same view, and they need to communicate together, the first thing that they think about is having a global state. And that is definitely an anti-pattern. Because the moment that you have a global state causing coupling (not) only on the code wise, but also the organization side. Let’s imagine that we have three teams working three different micro-frontends with a global state, and you are basically creating design time coupling. Because what you do is I need to add a new property in my global state, or I need to change a global state, and then I need to coordinate and test all the other micro-frontends.

Moreover, if you have a backend team that is working on some APIs, and you consume multiple time, and they change the contract, now you need to make sure that not only that the new contract is working but also that all the other micro-frontends are working. And therefore, you are creating more communication overhead, then you need to get them together with the teams and make sure everything is working. Instead, if you keep the state inside the micro-frontend, and you implement a Pub/Sub pattern where the communication is happening through an event emitter, or a custom event or a signal library or reactive stream. So you’re basically decoupling those systems where the only thing that you are exchanging is a contract, therefore an event. You are decoupling, first of all, the team, so as long as you respect, you know, what are the input of your micro-frontends and the output of your micro-frontends, everyone can plug without even bothering the team that is developing the micro-frontends.

But moreover, in an evolutionary architecture point of view, you start to add new micro-frontends in the same view, and they just check what are the events that the other are bubbling around and just plug themselves in. And if you think about that is the same difference between orchestration versus choreography within the microservices world. So you are trying to decouple that, and that has a knockout effect also on the team organization where you maintain the boundaries of the teams, so the team can work at their own speed. Testing and everything will be simplified. That is first of all one of the anti-pattern that I have seen.

The other thing that I’ve seen that definitely in my opinion may be classified as an anti-pattern is having multiple technologies in the same application. Many people are thinking, oh yeah, micro-frontends are a way to use Vue and Angular and React all together. We stitch all together, and off you go, you have your application. But what is important in a single page application, server side rendering application, is that performance is a key, especially because now we saw a raise of the users that are consuming our content on mobile devices. Therefore, 4G connection, 5G now, or 3G connection even, we need to be mindful of performance. My suggestion is define what are the boundaries. So the team can work with React 16, or React 17, React 18, Angular, whatever version. It doesn’t matter. But try to stick with the same theme.

If there is a situation where having for a certain period of time, multiple frameworks can be helpful. It happened also to us when I was working in DAZN where we applied a strangler pattern for micro-frontends. So we developed the first one. We push in production, and that was leaving alongside with our single page application. Why that? Because we want to create an iterative mindset for developers, where they start to push their code into production. Not being in fear of having changes in production, and that creates the mechanism around that for creating the confidence. So a fast CI/CD, creating canary releases, so you can shape the traffic on when things are going to old legacy applications. And potentially, the possibility to switch all the traffic to the legacy application that you know is going to work. Therefore, these kinds of mechanisms created the confidence for developers to move faster in their development experience, and also gaining real data and data points to compare and apply to improve their micro-frontend. I think that is invaluable because the moment that you are capable to do this, you create a flywheel that will allow developers to learn and be confident and create more code, then to be faster in their release. At the end of the day, we solved it. We moved from a few developments per month to tens of development per month, just because of this because the developers have the possibility in a matter of seconds to turn off all the traffic or reduce the traffic on specific browsers or specific devices. And that for me was fantastic because basically we achieved after a long time, one of the main goals that we had with this approach.

Starting with Micro-frontends Tips [00:40:43]

Henry Suryawirawan: [00:40:44] So thanks for sharing the tips. For example, you start with a small thing, right? Gain confidence, build a flywheel, iterative mindset. So any other tips for people who are sold into this idea? Okay. Micro-frontend. Let’s start it. Because for example, in microservice world, breaking up monolith is also not an easy thing. You will start probably by identifying seams, or fracture planes, or maybe a strangler pattern. What are some of the tips that you can give for people who want to try this on their monolith frontends, so to speak?

Luca Mezzalira: [00:41:12] So let’s assume that a team or a company finally decided micro-frontend is the right architecture for them, because that is the first thing I would say, first to understand if it really can provide the benefits to your organization. But secondly, I would say if you identify a micro-frontend can be helpful, start with a nice session in front of a whiteboard or digital whiteboard nowadays, where you are basically defining what are your domains. Let’s try to understand how they fit with the current organization, if you need to make some changes. When you identify one, try to take one vertical, one boundary that will allow you to test your assumptions. It doesn’t have to be the most complex one, and I would recommend not taking one with new features because otherwise, there are too many moving parts.

I prefer starting with something that is consolidated. It’s there, you know how it works deeply. You are a domain expert. You’re already developing it in a way. So take that. Start small, and it creates everything end-to-end. And trust me, you’re not going to have the perfect solution the first time. But you will learn a lot during the journey. And when you have done that, share the knowledge back to the company, and start to have contribution for other people. And then when you have that, you continue this approach, and start to improve slowly but steadily. One thing that I recommend, especially at the beginning, is having enough bandwidth, and keeping your backlog a bit of time for reviewing the CI/CD. Because that at the beginning will potentially slow you down, so you need to refine and streamline the key points. And definitely, the team should be empowered to change its own CI/CD, because in reality, you need to build it, owning your code. The moment that you don’t know how to build it, how to operate it, it’s impossible. You can’t maintain that code. So it’s very important.

Also micro-frontends, from the learnings that we had on microservices, that the team is responsible for that. If we do this, I think they can start to achieve some great results in short iterations, and then continue constantly to do that and accelerate as fast as you can, because that will be contagious. Everyone would like to do that, and when they see the benefit of it. They see that they are independent. They don’t have to coordinate anymore, and they can deploy a small portion of their business logic without retesting the entire application. Then I think we will be in a position where you start to see the benefit of this approach.

“Building Micro-frontends” Book [00:43:30]

Henry Suryawirawan: [00:43:30] Luca, you also wrote a book about micro-frontends, right? The title is “Building Micro-frontends”. So can you share a little bit about the book? What can people expect by reading the book?

Luca Mezzalira: [00:43:39] Yeah, absolutely. So the book currently is in an early release on the O’Reilly website. That will be ready by Q4 this year. The book basically is a work of two years of my life, where I not only learn a lot with DAZN, but I deliberately spend time talking with people, understanding their challenges, and see if my thought process was applicable in other context. Because in reality, DAZN was one context. Obviously, the world is way more complex than having just one. I saw a lot of benefit that change and twist my thought process several times. I have seen people applying what I was suggesting and being successful. Therefore, if you expect a book where you find tons of code on how to implement different frameworks, is exactly what you won’t find inside my book. What I’m sharing is more an approach for building micro-frontends, and learning the thought process. Because when you learn that, if tomorrow there is a new technology, you don’t have to relearn the basics. You know how to apply the core concept and their use.

I was very inspired by Sam Newman book on building microservices, and I try to keep exactly a similar approach where you work more on the code side. Obviously, there are some code snippets. There is a chapter where I show the implementation of micro-frontends, a couple of different implementations. But the idea is talking about organizational structure. How to sell micro-frontends inside the company? How to migrate a monolith to micro-frontends? What are the challenges you’re going to face? How to integrate with the backend? And showing different patterns to do that. The principles behind micro-frontend, so how to use them across the entire stack? And also there is a chapter I’m finishing right now, that is a comparison of all the different micro-frontends approaches – client side, server side, edge side, and the challenges that you face in all of them. Basically, these two years for me were extremely helpful because I was able to see different companies approaching the challenge that they face. I was able to speak in several conferences, and share what I’ve learned, and a different approach, and talk with people that are doing micro-frontends for potentially longer than me, and see their point of view and see how I was approaching similar problems in different angles.

I think I’m very proud of that, that many of the thought that I shared, I create a mental model for approaching micro-frontends, with all decision framework that I saw that was embraced in several talks and by the community widely. Therefore, I’m very proud of this contribution because obviously, it’s not easy creating a new architecture nowadays because we have a lot of architectures out there that are not changing very often. It’s not like a framework that you just release a new framework. An architecture is there for sticking and creating the foundation for that is extremely complex. Seeing that this specific chunk of work that I have done that basically is the result of six years of work, stick very well inside the community and was widely used, it made me very proud of the journey I’ve done, and makes me think that the thing that I’m rehearsing inside the book that would be more than 300 pages long, will contain the insights that the community is looking for.

Henry Suryawirawan: [00:46:43] Sounds very exciting. I’m looking forward to reading the book in Q4. Everyone who are really interested in learning more about micro-frontends, the architecture, the decision frameworks and things like that, make sure to check that out.

3 Tech Lead Wisdom [00:46:54]

Henry Suryawirawan: [00:46:54] So Luca, it’s been a pleasure talking to you. I have one last question for all my guests normally, which is to talk about your three technical leadership wisdom. Would you mind sharing some of the wisdom that you have learned from your career journey?

Luca Mezzalira: [00:47:07] Absolutely. So one thing that many people are not familiar with, but for me was a key turning point in my career was reading a book called “The Spirit of Kaizen”. In Japanese, Kaizen means continuous improvement. This is a practice that you can apply in your daily life, but also can be applicable on your day-to-day work. For me, it was fantastic because understanding that with small things, you can really achieve great results helped me to shape my mindset. An example for this, maybe seems very simple, but for me was extremely powerful. I started to read during commute time a chapter per day, and at the end of the year, you end up reading 20 books. So, yes, it’s literally 20, 30 minutes of reading, but it’s everyday, it’s constant. You’re creating a habit, and at the end of the day, you have big result.

And the same thing, I started to apply in everything I’m doing. So for instance, if I know that I have a large commitment, I start to break my commitment in small fixes. And then I know that maybe sometimes there are bitter pills that I don’t want to take, but I have to. Therefore, if I’m able to split them in multiple days, and take meaningful stat to see a progress of what I’m doing, definitely at the end of the day, we see great results. And these are also the same way how I tackle my books, as this one is the second book that I’m writing. I started dividing chapters, the paragraphs, and try to tackle small things. Because at the end of the day, I see that the end of the month I wrote 40 pages because every day I wrote a small part. That is the first one.

The other thing is engaging with the community. Don’t be afraid to speak with people. It doesn’t matter the role. It doesn’t matter what position that they are in. The reality is you can always learn from them, because maybe they have an angle of the same thing that you are convinced is right in your head that you didn’t explore. For me, I’ve been having this open mind on approaching everyone, and listening deeply on their point of view. It’s extremely powerful because then you gain a new insight in your head, and you start to elaborate that maybe you don’t use tomorrow. Maybe no, you won’t use this year. Maybe you will use in three years time, but your brain will pick it up, and that would be extremely powerful.

The last thing that I would say, I give back to the community. That’s how I grew personally. As I said, I’m a self-taught person, therefore, what I did was learning from others, and sharing back to others. And I think that was one of the coolest things that I have done in my life. I constantly do that. I try to write blog posts, record videos. I try to do talks. Not because I’m interested about the name, but because I have this forever debt with the community that I try to fill in somehow. All the times spending outside my job doing external activities, it’s more for trying to fill that. Because if it wasn’t for the community, I couldn’t be in the place of where I am right now. And therefore, I want the next person that is trying to take this path, will have a smoother path than I had back in the days.

Henry Suryawirawan: [00:49:57] Thanks for sharing the wisdom. Speaking about giving back to community, again, thanks for being a part of this podcast. So Luca, if people want to know more about you, they want to discuss about micro-frontends or maybe your book, is there a place where they can reach you online?

Luca Mezzalira: [00:50:10] Absolutely. So LinkedIn or Twitter, I’m extremely active in both of them. So feel free to add me. My first name, surname in both of them, so you can find me very quickly. Overall, if you search online, or especially on YouTube, you find tons of talks that I have done on that. So feel free to reach me out any time. As you can see, I’m a very approachable person. I definitely reply to everyone. There are a lot of nice stories that happen after opening to the community, and say yes to everything that obviously we don’t have time to tell. But I can tell you that these are extremely cool, and therefore feel free to reach me out anytime. I’m more than happy to answer all your questions.

Henry Suryawirawan: [00:50:46] Thanks again, Luca. So it’s really nice to have a chat with you. I wish you good luck with the book.

Luca Mezzalira: [00:50:51] Thank you, Henry and have a nice day.

– End –