Microfrontends: Cutting Through the Hype and Misconceptions (w/ Luca)

Micro-frontends promise to help teams scale development, but AWS Principal Architect Luca Mezzalira has seen some succeed and some just fall apart. In this conversation, he shares what he's learned from years of implementation work at companies like DAZN and through consulting with Fortune 500 organizations.
Luca explains why micro-frontends are fundamentally different from components—something many teams get wrong from the start. He discusses the common pitfalls he encounters: teams treating them like distributed components, sharing state across boundaries, and copying architectures from companies with completely different constraints and resources.
The discussion covers practical implementation details—from communication patterns and tooling strategies to when approaches like iframes actually make sense. Luca also touches on newer developments in server-side rendering and how they're changing the micro-frontend landscape.
This isn't about micro-frontends being good or bad, but about understanding when and how to use them appropriately. Luca emphasizes the importance of context and organizational design in making these architectural decisions work.

Our Fantastic Guest - Luca Mezzalira
I’m a software architect with over 20 years of experience helping organizations—from startups to Fortune 500s—design scalable, resilient, and modern architectures. My focus: evolving frontend systems, driving cloud-native modernizations, and enabling autonomy at scale through architectural clarity.
As Principal Serverless Specialist Solutions Architect at AWS, I advise global enterprises on designing and implementing efficient, event-driven systems. I specialize in serverless, micro-frontends, and distributed architectures that align technology strategy with long-term business outcomes.

LinkedIn
X/Twitter

Links and Resources
Luca's Newsletter 
Single-spa 
Module Federation 
Native Federation 
Web Fragments (Microsoft) 
Astro Server Islands 

Thank you very much for listening!

We are also pretty much on all social media platforms, so make sure to like and subscribe!

Homepage - https://www.weeklybrew.dev/

BlueSky - https://bsky.app/profile/weeklybrew.dev
Instagram - https://www.instagram.com/weeklydevsbrew/
TikTok - https://www.tiktok.com/@weeklybrew.dev
YouTube - https://www.youtube.com/@theweeklydevsbrew
LinkedIn - https://linkedin.com/company/the-weekly-dev-s-brew

Transcript

1:00:00

Hello, everyone. Welcome to another episode of The Weekly Dev's Brew. I'm here today with Luca. Do you do you mind introducing yourself real quick just for everyone to be aware of probably what we're going to talk about? Absolutely. So, hi, everyone. My name is Luca. I'm a specialist from AWS. 14 years I'm living in London. In the past 10 years, I work deeply on a topic that I'm quite passionate about, this distributed system on the front end, the four micro front ends. For many people knows about that. Delivered over 300 talks worldwide. Wrote three books. And yeah, that's that's me in a nutshell, basically. I said it before I hit the record button for this, but I follow you on social media for quite a while and particular about micro front end, which is a very which is a topic. Let's say it's a topic. Controversial topic. Yes. I love how you have very nuanced opinions about it and shared genuine insights instead of just going into the hype. So, just to level the playing field, how would you describe micro-frontend to me if like kind of like explain it like I'm five, right? It's micro front ends are a way to divide an application, a complex application into different modules that are loaded at runtime that are completely independent or tend to be completely independent that can be developed with the same or different technology choice. But the whole goal here is that are completely different from components because components they leak their domain into the container while micro-frontend are owning the domain and they just need a hunch of a couple of things like session token, idea of the product, stuff like that. That's the main difference between them. I think when you work in a mid-sized large organization or in a multi tenant application, micro-frontend can accelerate your throughput while if you are a team of five people and you struggle to coordinate by yourself, they're not a silver bullet at all. From my perspective, and I feel like the common case that I see people make is like, well, micro services on the back end side are so successful. Everyone is doing micro services now, which I also think is nonsense, but it kind of shifted the conversation more from like, hey, here are technical problems to like, well, we're already doing this on the back end side. Why are we not doing this on the front end side? Where they are like completely different constraints. So I would be curious if this is just my perception of like a little bit of the origin of micro-frontend, or if I'm not the only one that has that perception. No, no, no. So you can have micro-frontend with a monolithic code base on the back end, and vice versa. That is absolutely fine. Both of them are architectures and as architecture are designed or they created for announcing certain behaviors inside the social technical system. What I mean by social technical system is that I don't see a system just for the code that you're writing, but also for the people that are in the system, the four coders and teams and whatever, but as well also the engineering culture of the company. Because if we're not taking into account these three dimensions, we are making a disservice to the company. If we think that, oh, but I've seen Netflix using microservices and micro front ends, therefore it has to be in that way, or we don't do anything, we have big problems because 99% of the companies are not Netflix or Amazon or Microsoft or whatever. That's probably the thing that annoys me so much about this conversation because it's like these comparisons that are completely out of the air. Yeah, there might be a case study how successful Netflix run those things, but there's so much work that goes into that. They have so much more resources to cater those processes that are needed. So what I would like to do with you is look a little bit of the key characteristics that I see sometimes being referred to as benefits of micro-frontend, but also to some extent, they come with a cost as everything. The most common case that I see when people talk about micro-frontend is like, well, it's better for scalability. Where I'm like, what are we trying to scale here? It's not that we have the resource constraints as much as we do on the back end side, for instance, where hardware scaling is a constraint, resource scaling, but on the front end side, the code is usually executed on the client side. So we are having a one-to-one resource correlation. I would say that there is... Okay, so we need to split it up in two parts. So the first one is client side rendering. So client side rendering nowadays, I think, is laughable saying, talking about scalability, because when you have a CDN in front, it's very unlikely that you tear down a CDN, even with the US attack. It's up to throttle, great, but somewhere else in the world, the rules be a point of presence that we serve your content, so it's no problem. Now, server side rendering, it might help in certain situation. A classic example that I had quite few teams that I helped worldwide is the e-commerce. So when you have, for instance, if you think about e-commerce when there is, I don't know, a flash sale or Black Friday, there are areas of the application that inevitably will be hit harder than others. So probably an FAQ or contact us won't be hit as hard as personalization of a catalog or checkout, stuff like that. So definitely reasoning on, I have 10 millions of requests in an hour for the whole architecture that will hit a bunch of resources compared to, I need to cover the critical path that will be just, I don't know, the sign up and the checkout and the catalog. It will help on the cognitive load side, on the testing side, and also on the infrastructure side, because how you structure the thing. Now, I would say with React Server components, Azure Server Island, and all the other things, is another area where this approach of modularization could help on the scalability side, because there are inevitably some areas that will be awesome. I don't know if I'm thinking about a ticker for real-time stock data or sport or news, whatever. Definitely you will have some benefits, but that doesn't mean that everything has to be microfrontend. Scalability, I think, is definitely one thing that we need to think about, but it's mainly concerning server-side rendering application, also at certain scale, because nowadays even with server-side rendering, medium scale, I would say hundreds of thousands of requests per day, you can live with just a CDN, that would be more than enough. Yeah, the other thing that I often hear is like, well, we have multiple teams working on different things and allows them to make their own technical decisions, which on a high level sounds great. Usually though, most companies are rather aiming for consistencies, at least from my experience. So I feel like a little bit there's this trade-off going on of like, okay, we want teams to work independently, but we also want a certain level of consistency. How do you manage those to some extent contradicting? I don't believe you are contradicting. I think it's the mindset that has to shift in terms of, you can have a modularized and distributed application with a certain level of consistency. Now, if you're thinking, I want to have control on the library that are there, the version that are there, and whatever, probably you will have to spend a bit of time on automation, toolings, and governance. However, there are certain things that are mandatory for me. Like if you think about any web application design system, I want to have consistency there. Log in library, I want to have consistency there. Stuff like that, that are what they call cross-cutting concerns. I think that we need to have that part. And there are tools that enables us to reach that without being physically involved in certain conversations. So classic requests that I have from every team is, okay, so now we have 25 repositories. How can we make a change on a design system and apply to all the 25? The answer is dependable. That is one answer. It could be something else, right? So you just configure dependables where it depends how aggressive you want to be. You have teams that are even merging the pull requests automatically overnight when there is a new design system version. Others that are more mild, and therefore they are just opening the pull request and then checking that. But it's completely helped to the importance of one thing. Very often, if you think about rate of change or these cross-cutting concerns, like a login library, you're going to have maybe one change per year every six months. So therefore, the burden for doing this is not that huge. Even if you think about, okay, let's try to keep up with the same Angular React view version. They are pretty good nowadays on not introducing breaking change version by version. And therefore, it means if I remember, well, React last time the chat was two years before they have a breaking change on a version. Therefore, even one year would be, I mean, if you're not capable to update a version of your main framework after one year, there are different problems that we need to discuss. Fair point. Fair point. So that is one. The other example that I can bring on the table is stuff like budget size. So budget size, for instance, is important, right? Because if you think about distributed system on the front, and what matters is that you are not going to ship one megabyte of JavaScript on the client because otherwise you will impact your core web vitals and stuff like that. So you can create a shift left approach where through Gitooks, you can, let's say, compile on the fly your micro-frontend tend, see which is the final bundle size and assign a threshold to that specific, let's say, micro-frontend tend, and say, if you are over 30%, you cannot even merge. And I did that when I was working in DAZN, for instance. Nowadays, for instance, you can even enforce certain things in shared libraries. Like if you have a shared folder across multiple micro-frontends for, I don't know, classic thing header and footer, because are identical across the application, you can create some fitness functions that are basically test on your architecture that are automated. And therefore, every time that you open a PR, you can run the test and say, okay, perfect. So my test says that in the shared folder, I need to have two folders, one called header and one called footer. If someone tried to add something else, the test fails. That is up to you. You want to be notified by to the, I don't know, the tech leadership team, the staff engineer, whatever, or you want to stop this, this behavior is completely up to you how you want to design this behavior. But overall, I think nowadays, there are tools that mitigate the concern of I don't have the same control of monolith. Obviously, you are not going to have but there are also some perks on this trade off, because potentially you can say, I want to test the latest version of the Angular react because that could provide a competitive advantage for my application, you can do in your micro-frontend tend and make sure that that part can be tested in isolation, you don't have to coordinate the deployment, because if you did a good job, it will be just concerning a chunk of your system. So this trade off of adding a bit more thoughts on governance and tools, and automation comes with with the price of obviously investing this time on thinking about that. Also the benefit of the flexibility to say, I want to try a specific library of things, I can do that without coordinating with other teams. I didn't so much consider the case yet that you just as an example might have like even two different Angular versions and just try it out in like a smaller part less critical part of the application first. That's an interesting use case. What I'm wondering, from your experience, do you see this often in micro-frontend and architecture that companies use different frameworks, but also then different versions of frameworks? Yes, that I usually say is not the best practice. There are certain situations though that are inevitable. And I can give you a couple of examples on top of my head. The first one is the migration from one version of a framework to another one. Instead of going to the business and say, I need 18 months with the entire team to build this new version. Otherwise we are outdated or I don't know, we cannot find developers to do certain things. You can do it iteratively. And that is a big perk, especially for large enterprises that is like massive because they can start to add value and show value to the company straight away. And very often this is the currency for doing interesting project without compromising the thing that wants to achieve the business that is massive. Another example is when you work and there are many companies unfortunately in the enterprise world that are working with third parties and they have like this ecosystem is very fragmented with multiple third parties, internal developers, and they don't have control on CI, CD. They don't have control on a bunch of things in the world, especially in the financial ecosystem. There are plenty of them that unfortunately are complicated to handle. And therefore leveraging microfrontends helped them to shield, to accelerate obviously the development and shield some of the gotchas that you will have in a monolith without compromising a bit the performance, but vast majority of time are behind authentication. So in that case, the Core Web Vitals I cannot say are negligible, but close to because either you enter in your back account in that way, or there are any other way. I mean, you are willing to wait one second more potentially to see your final result on the back account. But you have the benefit that you have multiple companies and multiple teams working on the same application. One thing that I see most often people forget about Microfmicro-frontendontends particularly is that there is a good amount of stuff that you can just handle with tooling, right? Having good tooling practices in place mitigates a lot of some of that overhead. But at the end of the day, there's still you're shifting a little bit of like issues that you don't have in a monolithic architecture over to having clear guide, you need to establish clear guidelines, clear communications paths and processes. Kind of like you mentioned, okay, what happens if someone changes the footer? Who's responsible for that? How do we make sure this gets rolled out to everyone? How do you look at those issues? Because I mean, like tech issues are often, if not always easier to handle than communication issues. Completely. I think you are touching the right point here. So with micro-frontend pants, the main challenge is not technical, is we are getting back into architecture. I'm saying getting back because I have strong opinion, you might disagree with me. But I think that currently, in the last 10 years or more, in the JavaScript ecosystem, majority of the time we are saying, oh, yeah, we are designing an application with React and Redux Angular. But the reality, we're not designing anything. We are embracing something that is designed by someone else and applying patterns. Hi. When I read one more blog post that describes the perfect React architecture and is just listing folders, I'm going to jump out of this window. I love that. That's exactly my point. So I think we are back. I'm saying back because in the past, I didn't have air, but I have, let's say, Blackberry. And at the time, I was working with Flash. And there wasn't an ecosystem that was as rich as of today in JavaScript. There were a few frameworks. And very often, you didn't know that you didn't need that framework. I remember Korgorn or many others. So you create your MV star architecture. So you write it down from scratch, creating your model, view, controller, presenter, view model, whatever it is. And I think there, you really need to understand patterns in architecture because you start from scratch, you write it, the foundational part for you from scratch. Here nowadays, it's like, oh, I choose my library that goes along with React. But without even understanding the behind the scene of the library, it's just vast majority of the time based on hype. Or, oh, I know that working in that company, therefore, is going to work on mine. In the past, when I was working in DAZN, I was at the beginning architect, then became VP. And in my team, when we embark into the micro-frontend approach, I said to the small team I had at the beginning, choose whatever you want. I don't want to impose one thing. I have my preferences, but I want to see what is comfortable for you because I believe this architecture will enable us to do whatever we need properly despite the library. And they went with React and MobX state tree. And I was a big fan of MobX compared to Redux because it allows you to generate a tree of states that are pluggable and unpluggable. So you can remove from memory a specific state if you are moving away from the view. And that at some point, the average collector will, let's say, collect and dispose basically the code there. And the reason for me was key. That part is because it's not that we can always work on a tank or M4 MacBook Pro. In our case, 60, 70% of our audience was consuming content in living room devices that were, I don't know, a fire TV stick from 2015, or Google Chrome, or a set of box that was with HTML4. So it's like that kind of stuff. So every by and others and having a modern solution that was fully reactive designed amazingly, because I know Michel very well, and now he's working in META and he did an outstanding job, in my opinion, with MobX at the time, I think was the right choice compared to others that maybe introduce singletons in memory and the stick with everything that is in the state forever and ever, but no one checks because nowadays, our iPhone is definitely more powerful than basically everything else that I work with in the past 20 years. I think DAZN is also a particularly difficult problem because as you said, you have to fire sticks and those things that are outdated, low performing. How, I mean, like just looking at things like DAZN, for instance, you still have those instances where you share information across microfrontends. How do you, I mean, I know there are a couple of different approaches, but what have in the past seemed to work well for you? What would you recommend teams? Because it's kind of like breaking the idea of microfrontends, but it's also often a necessity. Take one view or group of views and that is a microfrontend that was big enough to, let's say, feed one team with the complexity we were handling. We screwed up just one at the beginning. There was the onboarding, we call it. There was an instant up payment. I remember email, remember password because there was too much cognitive load, especially first few countries. Great. When you reach 200 countries on payment, it was massive. And therefore we split into teams. That was the only one that we screwed up. Then we made some announcement, like the video player was a component that was included at build time. I was very ruthless on certain decisions or certain guardrails. Everything that is a shared component is not runtime because runtime can work on pre-prod, but they might blew up in prod. Despite all the things I have on developers, there are certain things that are difficult to test. Especially when you have a lot of moving parts backhand on microservices, frontend and microfrontends, you need to be safe. Having the frame that basically the library that you need to bump up in the package JSON allows us to go through different tests, then working parallel in this integration and then blew up in production. But the communication in that case was simple. We rely either on an API, so we store on the back end certain information, or we rely on a global object that was exposed at the beginning by the application shell that is the container of the microfrontends basically. Because every client side rendering application probably you have the same experience. 99% of the time the first thing you do monolith or microfrontend is calling an API. I want to know where I am, what I'm doing, what are my feature flags, whatever. And that's what's happening in our case. So we take that thing or that API and expose these in an object that was freeze through JavaScript. Therefore, they cannot tamper it through JavaScript in any way. They can read, but they cannot do much more than that. And that enables us to, let's say, communicate at the beginning that way. Then if you instead you have multiple microfrontends in the same view, the thing is more complicated. The three ways that they usually recommend is not sharing any state. You don't share anything. It's literally every microfrontend is its own state because otherwise you cannot create independence. What you share is events. Classic Pub-Sub thing that I was used to do on back end, and with event driven architecture became normal, and therefore applied also the front end. There are three ways, main ways that I recommend is either through an event emitter, custom events, or observables. Now, the last two are not a huge fan of observables, mainly because you can have bidirectional observables for your subject in Rx, for instance. But the challenge is there is a deep curve to learn reactive programming. And I wrote a book on that, so I kind of deep dive into that quite a bit. And I've seen, let's say, developers struggling a lot with these concepts. Therefore, I tend to say, okay, so if you have a team that is extremely well, let's say, trained with observables and reactive programming, great, but otherwise, park it. Custom events has the problem that are bounded to the DOM structure. Because usually, if you bubble the event up to the window in another branch, I need to plug myself into window of the listener, right? But I can have someone in the middle that does event.prevent even default, and I would never find a bug, or better, I will find it, but let's say it would be a long time. Basically not. We said event emitter basically democratized the communication. It's just subscribing, and the subscription happens through storing a pointer to an array, basically. And then I just say to that object, someone, I mean, to this event, are you interested? Yes, no, who cares? And if you're not interested, you will receive the event, but it doesn't impact your performance. And the beauty of this is that then you can create like a typed event within an object that is defined in a shell library and TypeScript to use TypeScript. So there are a lot of ways that you can design these things in a very nice and clean way, even testing became easy. Because as long as I know that my team has this contract, and you have another contract, and you want to integrate with me, then you say, okay, so Luca is sending me this, perfect. So let me create a test for this, or let me create this scenario that I can do through end-to-end testing in isolation without having, let's say, Luca's team micro-frontend 10. So there are a lot of benefits if you look holistically on this approach, while with the shared state, you are is a recipe for disaster in, and I've seen quite a few companies unfortunately go into that truth and refactor for six months. Yeah, I can totally imagine that. I'm kind of curious to hear your thoughts on the signal proposal that is out there right now. Do you think this one of my first gut reaction was this might solve sounds so harsh, but might be a very viable approach to sharing state across microfrontends, if it turns out to have those capabilities, right? But just like conceptually, the idea of like, okay, having a shared way of having a general layer how to share state that is adopted by the most common frameworks, could be a great way to have a reactive approach without like having the overhead of something like ARCs. Is that just my wishful thinking? Or do you see this in a similar way? I think you're right, it could be an interesting approach. The problem is in the micro-frontend 10 fashion, you shouldn't have, let's say, too much to share because otherwise, you are building components or better distributed components that is the enemy and evil in every architecture. Because the problem is, I don't see the big issue on containing the state inside each micro-frontend 10 is easier for testing is easier to deliver stuff. And at the end of the day, if you do a really good job on designing this, you invest time at the beginning to say, okay, let me think what are the domains here, then it big events are negligible, like, I don't know, I've 10 events top purview, that is like, literally nothing compared to the grand scheme of things. And then you need to be smart enough to recognize that certain things doesn't have to be designed in a very granular fashion, you can, let's say, stay more coarse grain. And for instance, I don't know, an FAQ page or an help page is basically a view of a headless CMS that is majority of the time handled by the customer support or the marketing team, that is putting data there that there is no need of creating bazillion of micro-frontends to load there, when you have like a micro-frontend tend it is pushed into another between header and footer. Done. I mean, you forget about that, you probably the maintenance of that is the rate of change that part is negligible, it would be probably one person every x month. So I think there is this kind of discussion and I spoke a lot in the new version of my book, where I started to create the heuristics that I learned in the trenches talking with customers and worldwide, and rate of change is one of the Heuristics. So how often do you change? Because if you change once every six months or a year, there is no need of modularizing that like co locate the code, it doesn't really matter. The effort is more creating the governance and the complexity on handling the stuff more than creating something that is more monolithic or co located. And that's exactly what I meant in the beginning with nuance perspective on this. One thing I would be curious to hear your opinion on is how do you see mono repositories in that whole conversation of micro frontends? Okay, so this is a question I remember seven years ago when they asked me the first time, I was a little bit puzzled because I didn't immediately get okay, why monorepo will be better than poly repo and vice versa, because I work with both and both works. Right depends what what you need to do. So the reason I'm saying that is this one. So for me, the moment that you select a mono or poly repo, you're basically selecting how your teams, your teams inside the project will work. Yeah, in terms of engineering practices and communication. So if I choose a mono repo, what I want is everyone has visibility of what's happening. But I also force people to work in a trunk based development approach with short living branch. And if I have a if I have a team or better company that has few seniors and an army of juniors, that might be complicated. Because you will need to accept the fact that for a certain period of time, six months, a year, wherever it is, you will struggle to get stuff at the velocity that you expect. And also, there could be that maybe main is broken. And therefore, you need to rush for fixing it that could possibly generate some tech debt that you need to fix later on. So I think this is a cultural engineering cultural decision that you need to take. But it can work perfectly. The reason the other the other thing that is important mono repo to remember is that at some point, you will reach a moment if especially if you have back and front and maybe mobile and web etc, that the traditional tools might not be enough. That is so true. And you need to accept that. So it's something that that that you like it or not, is something that you accept with the moment that you accept the velocity, you accept the fact that you are, let's say, designing things and shipping things faster. Therefore, feature flags can only release stuff like that. But you need to have a certain level of knowledge and comfort on building this stuff. And now everyone is that that scenario in my experience, the other side, you provide less discoverability, because I cannot unless I know the name of the repository, I cannot do my I can search but maybe maybe GitHub doesn't tell me which is the repo. And that basically provides a behavior on on the between teams that if I want to communicate with your team, and I don't know what is your repo, we need to sit down and create maybe write down a request for comment, or an ADR, whatever you need to do. And that for me is very interesting, because now we shift the conversation from all which is best to watch behavior we want to have inside the social technical system that I prefer by far, to be honest, because both of them are viable. I have seen companies succeeding with both. But the thing is, is by far more interesting to understand which behavior you want to have inside the company. You want to have, for instance, poly repo, micron, tensor interesting, because think about independent teams, these will create independence, they will allow to use whatever tools that they need. And you force the teams that if they need to exchange information, they have to do it. On the other side, you accelerate the development, you accelerate the integration, you might find certain scenarios where all in the shared library, now I have 25 things that should be shouldn't be shared, but are shared because it is the share. And these behavior that you need to take into account. And I'm not saying this right or wrong. I'm just saying, if your context drives this decision, for me, both of them are, I've seen companies working with both of them, and with different outcomes, some of them fail miserably, we both have some of those succeed very well with both. So for me, everything boils down on really understanding the context that you're operating. If there are a mix of junior and senior accepting or selling to the business, by the way, we have to buy some time at the beginning if we work in Monteripo to let's say, skill up all the people to this approach, but then we will have certain benefits. And to be honest, I did something similar in my previous, my first job in London, where we started to have an automation that merged every single branch out of Maine, every four hours. So you couldn't have, let's say, a branch that could more than four hours living. And the beauty is that the first month, we started to slow down, but then forced us when we do the sprint review and defining what was the next sprint and the task for the next sprint, to be extremely precise and thinking thoroughly about how big is this task? Because it's more than four hours, I'm screwed. So I need to divide it in smaller chunks that can work without breaking things. And therefore, we find ourselves after a few months that our team was the one that was every single time delivering on time and more than what we expected, because we didn't have to spend the last two days merging code that had too many conflicts and rebasing and stuff like that. We just literally shipped normally. One thing I would be curious to hear from you, did you have kind of like clear indicators where you say, oh, if you have those X criteria, it probably makes sense in your context to stick with something like micro-frontend or the vice versa. And I know this is a little black and white, but I think this could help some people really look at it more objectively like, okay, I don't have this. Why do I think micro-frontend is still a good choice? One dimension is definitely team size. Yeah, I think to be honest, nowadays, there are no excuses that team of 10 people, in my opinion, at least should work easily inside the same code base, despite maybe that there are some friction inside the teams, but yeah, we are human beings. But there are certain scenarios that if you have 10 people, I have, for instance, a customer in Canada, that I have a team of 14 people that are still decent enough for working in the same code base. But they decided to go with micro-frontends because they are doing a SUS product where 80% of the code is exactly the same for everyone. So signing in, signing up, the onboarding experience, the FAQ, whatever. But they have, because they build basically a software for iPad, the classic electronic teal that you have when you go to the restaurant, where you have like a design of the restaurant and the table, stuff like that, that part can be customized. Depends which, if you have like delivery or take away, if you have a restaurant only. And therefore, they created this modular approach where basically they have mainly free micro-frontend 10s. Two are the initial part if you need to configure stuff. Another one is when you are inside the common part, and then the standard generic thing on how to handle a restaurant and then the customization based on customer. And that basically helps them because in order to put together an application, basically 70% of the application is identical. Just ship the same thing. And the rest is either generic with some custom capabilities that are predefined or completely custom. And that has a big help on this small team, mainly also on deployment. Because they know that if they make a change on the onboarding experience, it will be across all the customers. But and therefore, they just deploy the application done, the micro-frontend 10. If it's instead a specific customer that requires a massive change, they know that won't impact all the rest. There is no feature flex. There is nothing else. It's literally a different files that will be uploaded in the server or CDN, whatever. I think one thing that I often miss in the conversation around micro-frontend and the set level that you just brought in of granularity, right? Often when people talk about micro-frontend and say, well, every view needs to be its own micro-frontend or every... I think there's like a... This granularity aspect is super important because you could still call yourself a micro-frontend and if you just say, oh, we have the main application, we have the lock-in flow because that's dependent by a different team. Absolutely. But this level of nuance often gets completely missed in the conversation. Completely, yes. And with that, also the level of complexity changes because if you know, oh, well, the lock-in flow is handled by this other team and it changes once every six years because we need to update our copyright information. That's a different piece than when you say, oh, we have 30 teams that... That's probably the part that annoys me so much about this topic. It's like, it's a super interesting discussion. There are so many different technical aspects that feed into that, but it often just boils down to, well, everything has to be... Either everything has to be a micro-frontend or nothing. And that is so not fitting in the world we're living. I totally understand. And I think everything is related to my, let's say, strong statement at the beginning, we are back designing applications because we are not... We weren't used. So if you think about people that joined in the JavaScript wagon in the last 10 years, we were talking about millions of people, their experience is, I choose Angular, React, Redux, done. That's basically what I do. And you don't think about... If you choose one of those, your only thought that keeps at night is the performance on how to do a full cycle or how to do other things. But here we're talking about designing architecture. I can tell you, I can mirror the same experience on the microservice part. Because as I said, I'm working on the serverless side of AWS that for Lambda is one of the services that I cover. There is an antipat and call Lambda Pimble that basically is communicating between the chain of Lambda call one after the other. That is, you can technically, but you are not designing things properly. Because basically, you're adding latency, it's not designed for doing that. You're spending way more than what it should be. And then the answer is, oh, but serverless doesn't work. Instead of thinking about the architecture is complicated. So you need to think about what you're doing. It's not just, I write some code and you ship it. You need to understand the level of granularity. I started to borrow basically this concept that is coming from Neal Ford and Mark Richards, my superheroes on architecture, about integrators and disintegrators for microservices and apply to microfrontends. You need to understand when you co-locate code and when you don't. And the context drives that. It's not me saying, oh, the header must be a microfrontend. To give an example, in DAZN, the header wasn't a microfrontend. It was built five times because we have five microfrontends on the web application. Because I trust the team that are capable to replicate, even if it's not pixel perfect, a header that changes, I checked before saying that. In three years, we changed twice. So there is no need of building and external things that when time comes, it becomes more the time of defining who is doing what, because no one touches for a year and a half. While I need to create five tickets on Jira for changing, adding a new menu item or changing the logo or stuff like that. And the effort for my developers is basically 30 minutes. So I'm not going to do that. And this, let's say, holistic view, this often is missing when we are building a system because we try to say, oh, we break down the system in microfrontends. So everything has to be microfrontends. But also why, in my book, I didn't spend time telling you, oh, you write the code in this way. I'm definitely not the best React or Angular or view developer in the world. But my unfair advantage is on architecture, because I know how to design both sides. And therefore, I'm focusing on what really hurt in microfrontends. That is the architecture part. Funny enough, I have a similar story, the best architect I've worked with in my career. And this was for a frontend project, was a Java guy, has never touched web stuff. But that actually helped him to take these steps back and be like, I don't care if you use Redux or whatever. Here are the constraints that I want to have in the system. I am curious, though, when do you think or can you pinpoint what changed this conversation from like, okay, here, folder structure is architecture, or a text that defines the architecture from like, okay, let's talk more about system design. Can you pinpoint that when you notice that change in the conversation? At the moment, I would say that I have seen a mixed approach by companies. We become more aware of this topic, I would say, in the last three, four years. There is an acceleration of microfrontends project that I followed in the last three years that I didn't expect to be honest with you, by companies that with names that probably everyone knows. And when they started when I luckily, you know, working at AWS allows me to speak with those companies. And therefore, when I started to pitch how they should approach it, there was this ha ha moment in their face that immediately clicked. And people started to, let's say, disseminate this idea. But, you know, I spoke with a lot of people worldwide that they started to think about that the main struggle is still the way how you split microfrontends. Because as you said, everyone thinks about components or the library or the folder structure, whatever. That doesn't mean anything. And also, to be fair, I think that is also the biggest struggle on the back end side. There are frameworks in place that help with that. But also with microservices, I've seen companies and I've worked with companies that went unnecessarily way too granular just for the sake of well, we're doing microservices. So everything has to be a microservice. Yeah, I agree. And I had one point on this, because it's close to my heart. Don't blame the architecture. If you went to granular, it's not the architecture, the problem. Our decision made by people. And in certain contexts, it might work. There is a fantastic talk I remember for the rest of my life that I attended where there was a company. I'm not going to name the company, but there was this person saying, oh, yeah, because before we had four microservices for integrating with third party systems. And we discovered that microservices are rubbish. Useless architecture. And now we create a unique monolith and we work way better, throughput high, stuff like that. And then someone asking during the conference, listen, but, okay, so microservices are rubbish. What changed in your ecosystem? Oh, yes, at the beginning, we were four teams for microservices. It makes sense to me. Now we are just one. And therefore, handling four microservices is complicated. But then the context changed. And therefore, you need to adapt the architecture to what the context was. That is a very different story from what you tell us. Yes. And that's, I feel like for me, most often what it boils down to, it's like, you described this as context, I always consider it more like constraints, right? Like, what is the staff we work on? What is the system we work on? What does the business side look like? And I don't know if this is just a JavaScript problem or I feel like often those parts that really should be the driver of the conversation are not even in the conversation. So that's probably my biggest issue that I have with microfrontends, because I absolutely think it's a viable approach. It solves a lot of issues that are otherwise really difficult to handle in a different technical approach. But like, this conversation is always like, it's the best things in sliced bread, where you're like, nothing is in tech without issues. It's just not how this works. So I absolutely appreciate your perspective on that. What would you say from your perspective are the biggest reasons people fail with micro frontend architectures? The biggest reason, I have a full talk about the antipatterns that I collected. Okay, it was fun. The main reason is thinking about microfrontends like runtime components. That is by far the main one. The second one is sharing the state. And then don't understand the coupling that basically that is not technical. The problem is not technical at all. It's the communication between teams. Because the moment that I want to change, I assume that that is a number, but you change in a string and no one communicate that. And good luck. Yeah. Can you elaborate more on the looking at microfrontends as components? How do you distinguish those? Yeah, the thing is simple. So when if you think about a component like classic one that I take is button because everyone thinks that knows how the button works. So you basically what you do is creating a bunch of properties because your intent and expose a bunch of properties and create a bunch of capabilities inside the button that could be, I don't know, that is auto sizing because you handle internationalization or you have a rollover animation or you have enabled, disabled, stuff like that. And then you expose them, right? Because the button doesn't know where it will be used. It could be a form or could be, let's say, inside a hero component or whatever. And they are basically what you want to express technically is you want to have a reusability because you want that the component is consistent, as we said at the beginning. And we want to have the capability to avoid duplication. Because otherwise you are going to have a position. So those are the things that you express inside your code. Unintentionally, you don't think about that, but this is what you want to achieve. But what happens, though, is that you take the component as a button and you are using a form in your team. And therefore you set that is enabled, disabled, depends from the mandatory field that are available in a form. I am not going to do that because I don't have a form. I have my hero component. And I just need to, when I click, it goes to the right product. As simple as that. So what it means is that now the button or the component leaks its domain to the container. So the container owns the domain, so in my case, the hero component, and says, okay, I instruct you to behave in this way. Therefore, the button itself is meaningless about the context. The container, though, is very well aware. And if you start to think about this approach in Microfrontends, what it has is the context. So the context is well encapsulated in the Microfrontend. How do you express context in Frontend through State Manager nowadays? Before it was modeled as a controller, today is the State Manager. So State Manager is your context. Therefore, if you are capable to slice it, and the context can be more coarse-grained or smaller, there is no right or wrong here, right? Because it depends from the context. So your State Manager will be, let's say, representing the behavior of a specific area. And you need to be careful on how to slice things because you might see that there are certain things that are common. For instance, if you think about e-commerce in a homepage, you have a lot of subdomains. You have maybe the best sellers. You have the latest things that were released. You have also maybe some information on marketing. Maybe you have some services that you're selling or support stuff. So if you start to look into that, some of them can be Microfrontends owned by the same team that are doing catalog in the case of best seller or the hero component. And they basically hand over a chunk of their logic because they probably own the backend and the frontend to the team responsible for the homepage. So now it starts to become very interesting now because if I slice in this way, the team responsible for the homepage, maybe you have a chunk of the system, but they won't have the best sellers, stuff like that. So my communication flow inside the teams becomes very streamlined because I'm responsible for the catalog. So I build the catalog, I change the way that I want, speak with the marketing on that part, I design the API, boom, I have everything. On the other side, the end over part will be, oh, this is the end point for loading the best seller. How is going to behave there as long they respect my guidance on don't create something that goes over in that index 1000 and therefore it will be on top of everything. It will be good to go. I can communicate with it, potentially I can't react if I have an event. And now everything becomes very streamlined, but I approach this design not from, oh, this is a component. I approach the design on what I need to express here, how my team are going to own the cognitive load on that, how they're going to interact. You see that this is completely different from I want to abstract three lines of code because I don't want to repeat multiple times to, I need to see my organization, how is it going to behave? And these are the behaviors I want to see inside the social technical system. And that's the main difference between who is designing an architecture back and front and as a mother and who is implementing blindly some code. That is a way more in detailed answer than I expected when I asked the question. I tend to collect a lot of thought and then I don't think I, so as a fair disclaimer, I also never implemented a micro-frontend in architecture. So this is just based on experience and or like based on experience on the other side of things. But I didn't consider the aspect of ownership really, whereas the micro-frontend ideally is like self-autonomous other than Shell put it somewhere. And a component being like, well, but the container is responsible for that. So that's a really interesting aspect. And I think that would help me a lot in like the way I would slice and dice a micro fronted. Because this pattern of like, okay, who is responsible for what part of the application? It's usually even for the people that are more in the way of like structure components, a common pattern, where it's like, is this self-contained component kind of like micro frontend in that context? Or is there something reusable that needs to be in the ownership of someone else just with a common behavior across our system? But the component is easy to design to a certain extent, because you provide basically, I don't know, an API at the end, as the button has these four properties available, you want something else, you ask me. The micro-frontend is not, is nuanced. And therefore, you need to understand the system that you're building. That's why very often, you know, even in AWS with customers, I always say, the first thing you need to understand is what the business wants inside the system, what they need to express, what are the architecture characteristics that you need to layer up on the business side, and then you start to think about what are the tools that they need, could be serverless, non serverless, whatever, and what are the trade offs that you need to take into account, because certain architecture characteristics are mandatory for certain industries. I don't know if you're thinking about finance, they need to have maybe multi cloud, or they need to have something on prem and something in a cloud provider, or they need to have, in my case, in DAZB was availability. So I cannot, let's say, allow someone to tear down the Champions League final in Germany, because otherwise, they're going to scream correctly. So because football is important. When we launched in Italy, the first thing I said to the CTO is, you don't have to touch pizza and football into Italians. Otherwise, we are screwed. Yep. And that's what we designed for. So every single decision was shielding the critical path. And let's say if some part didn't work, fine, we accept that. And we design everything in this way from the front end to the back end, everything we had a lot of thoughts around that part. But everything was based on certain inputs that were coming from business plus the context that we were the architecture that we were designing. And that is part in my opinion, that we are missing on on the front end side, because I noticed this decentralization of architecture design towards team back and front end. But there is no coaching. There is like a bunch of developers that nowadays with this shift left movement, they found themselves to do security coding, testing, architecture, design, wherever. And we expect that they know everything about any kind of topic that is not the case, because poor guys, I mean, I would be swamped by by all these kinds of things. There are so much to understand, because the complexity of the system is not the same that we had 15 years ago, or 20 years ago. So we need, in my opinion, to shift a bit this approach in something because I think it's a pendulum, right? So before everything's centralized, I worry tower and everything. Now we decentralize everything, we will eventually arrive to the middle, where I think, for instance, the architecture team will be critical for coaching, not for taking decision for all things, certain things, but for maintaining that bridge between business needs, architecture, characteristics, and helping developers to think differently through questions coaching is not I tell you the answer is, I raise the right question, then you learn how to raise the question, right during time. So you are autonomous at some point, I think these will be the next wave of architecture teams, then I know that I'm a visionary, and very often these things are not happening. This at least how I would handle it. I would hope you're right there with that. That is a prediction that I would like to see myself. I have one more question about microfrontal. And it's probably a question two parts. One big aspect of microfrontal, as we talked about this is the stitching aspect, right? Like I might have one page for the users that consists of multiple microfrontals. What are approaches for you that seem to be successful? And I don't mean this in any diminishing way, or the most common approach I've seen is iframes, where like every, like my my tone is curled when I just say that name as a developer. Even though objectively, there's nothing wrong with iframe. So I just would be curious to hear where your approaches that you have used to that make really good use of this that worked well. And what would you recommend people to look into? So in my frames for me are still a viable option in certain cases. Recently, like literally four months ago, I had the team internally in Amazon was we were talking about much federation, that is another library that you can use for doing that. We started to ask, okay, tell me more about that. So when I started to understand their context was a team that was responsible for the application shell. So the coordinator, the router and everything of the system. But the micro-frontend dense loading is the system, they have no clue where they're coming from. They're coming from different teams that have they cannot impact the library they're using, they cannot choose about the way how they're building things, they cannot plug themselves in having visibility in the code base on it, they literally have a bundle that is arriving to a certain URL as it and they told me, oh, yeah, we can do with Module federation. Yes. But the thing is, you are a B2B system behind authentication, there is no way that you can access in any other way. And you need to load stuff that you cannot control. So you need to sandbox it in somehow. Yes. And iframe is perfect, I can just shield everything that is happening there, you live inside your window, because they have another problem, there was a big one, there was a library, it was appending itself inside window. And therefore, if you're using more federation, no matter how you encapsulate the things, you're going to have a problem. And therefore, iframe for that use case makes sense. Nowadays, thanks God, we don't have many use cases like this that has this complexity that has to be handled and team are so detached. Nowadays, what I'm seeing majority of the time is for client side rendering, either module federation or Single-spa, those are the two main one. Module federation because it's, I think, transparent, is the objective that I think about. So I implement it. It's obviously, you have to configure it in a certain way in order to make it work. But I can have multiple reactive version in the same view, or Angular, whatever library use. But it handles very nicely the single-tone approach of loading one dependency once during the live side of the user session. That's great. And single SPA is identical, provides also on top of that, the module federation is thinking about integrating the hooks. So I can have some lifecycle hooks that when a micro-frontend is loaded, I do something else. Classic thing. And those kind of things, I think those two are the most, I would say, client side rendering 95% of my engagement with customers, if not more, is with these two. And they handle very nicely in single SPA. They do either using system JS or import maps. They are the laws, let's say, the web standards. And those, in that case, in import maps and system JS, you can create what they call scopes. So you can shield the code that is running inside the scope, not like an iframe, because you don't create an object. But the scope will remain inside there. Therefore, you can have the similar approach from module federation. In Angular, there is native federation created by Manfred, that is a fantastic Angular hero, in my opinion. Doing so much great work around that. I love his work. And he basically takes the approach of module federation without using module federation, using web standards. So behind the scenes, basically, he's doing import maps. He's a completely obstructed API, basically, on that. And this brilliant works very nicely with Vue. I've seen work with Angular. But I didn't see too often outside the Angular world, to be honest. As far as I know, last time I spoke with him a few months ago, he was telling me that the Angular team is recommending native federation as a way to go if you want to use microfence with Angular. So that's great. It's a great validation. He did an outstanding job, in my opinion. So it's absolutely great. Cyber side rendering is complicated. I have more hope than a few years back. Okay. So Vercel just announced the microfence public beta. That is great. Because if we have big players like them that are entering the game, we have some, usually are quite savvy on the JavaScript side, opinionated, but savvy. I think there is a lot of great stuff that comes up on that side. We have others, like, for instance, Astro has Astro server island that basically, I don't know if they steal the idea or they copy the idea. I don't know how it works, because it was an American thing. But the thing is, back in the days, Preact had this idea of islands. And when I spoke with, I never remember his name, Jason, I think it's called. Yes. I have the profile picture in front of me. I have the picture in my head as well. I think it's Jason. I spoke with him back in the days before Preact 10. So we were talking about 2018. I was Google developer expert. So I meet with the guys there in San Francisco very often. And we were talking about that. I said, "Listen, but is an island a microfence from 10th?" And they told me, "Oh, no, it's something similar." I said,"Okay, let's take a step back. What are the characteristics of an island?" So I can ship independently. More he was telling me about that. More,"Okay, this is a micro-frontend 10.""Do you call it island, but it's a micro-frontend 10?" It has exactly the same characteristics. So I started to use server island on Astro. It's super cool. It's like React server components. So it's a chunk of a view that can be rendered on the server, but then streamed into the client. So if you have, for instance, an example that I created for my book is if I have a dashboard, OpenServe ability dashboard, and you want to refresh in different widgets. One is signaling the core web vitals, another one the logs, another one the availability. You can do that with different APIs. And therefore, they do server side rendering on the server and send the meta code that then is used by, in the case of the server component, would be a sort of React DOM, that would be a pending in the virtual DOM, and then rendering in the real DOM. In the case of Astro, it would be HTML with the hydration that you can happen in the client. But in my opinion, it's brilliant. The direction of travel is exactly what I want because you can't decide how granular it is. In my case, it was a widget, but no one is stopping you to be a page or something more. So you cannot layer up all the things that we discussed before on slicing a micro-frontend dance application, and then say, okay, my composition is rendering complex stuff on the server that will benefit also low hand devices. Like if I have a web application running in India or Brazil, where the connection and the devices are not as strong maybe as, I don't know, UK or North America, then you have benefit also there. That I think is kind of a brilliant approach. But all of them, boys down, I've seen recently web fragments from Microsoft that they released a month ago. That's right. That's right. Yep. Natalia, I was talking with Natalia, we'll explain a bit how it works behind the scene. And basically, the interesting part is everything boils down into transclusion. There's a whole technique we're using at Site Include, where basically you have a placeholder and you replace it with real DOM. That's pretty much what is transclusion. All of them is server side rendering works in this way. You can call them through passing proprietary meta language like React, you can call it like you pass naked HTML fragments, it doesn't really matter. But that is what boils down. If you start to think about that, then it becomes just how you express transclusion. I did, for instance, in AWS a few years back with HTML fragments, like as Zalando was doing back in the days, probably you know Zalando very well. And they were doing basically HTML fragments. They were sharing HTML fragments and everything work. Then they moved away from that approach to have more constrained approach using React and GraphQL, rightly so because they were growing and they learn how to do these things. But they also learned that they kind of grant the possibility to do whatever framework, whatever framework you want, because it will have an impact on your core web vitals and for them was critical. But in general, I think server side rendering is transclusion the way and therefore everything that we described before on co-location and co-location and granularity should be applied on server side. Just pick wherever your framework of choice will make it. I love how you automatically answered the second part of my question because I was wondering how you feel about React server components and those technologies in that context. So that was peak efficiency. I love that. Yeah, sorry. I spent a lot of time thinking about this stuff. That's basically where my nights are going. It's fantastic. Perfect podcast guests. So I have one last question for you before I let you go. As this podcast is called the weekly Devsper and it's highly themed by my borderline coffee addiction, do you notice any severe impact from your move from Italy to the land of tea? So London in the last five, six years enabled me to find a lot of Italian food and coffee in a very easy way. In fact, I don't have an espresso capsules at home. I have the Italy capsules. That is one of the brands that I usually drink in Italy. But the other cool thing is the last six, seven years, the amount of amazing coffee shop that are available in UK in general and in London in particular is insane. I taste certain things that in Italy I would never taste. The only drawback of this, so with the pitfalls, is that the speed of delivery of an espresso in Italy is like they can do 10 compared to one that they usually do in London. Yes. Last year I was in Italy and I love this fact that you literally get like, I think it's a zero or a dollar. It's pretty cheap for espresso and it's consistently good espresso. Yes. I think I really just had a handful of very, very good espresso but I also didn't have like a single bad one where here in the US where I live now, it's a little bit of a gamble. You pay probably more like four to five dollars for an espresso and you can get a fantastic one, well balanced and everything but you also might pay four to five dollars to get a really, really bad one. Yes. I love that about Italy. I was literally at a gas station on the highway, stopped in for an espresso and it was a really solid espresso. There was nothing wrong with it. That's the beauty of living there. With food we are good. Yes, yes, very good. All right, thank you so much Luca for joining me. This was great. I had a fantastic time. I said it in the beginning. I said it throughout this podcast but I appreciate the nuanced opinions you bring to this conversation. I think this is really what JavaScript people need sometimes. I hope that was helpful also to set a bit the scene because as you said very often there are these misconceptions about microcontents that either all in or nothing, there's no such thing. You just need to understand the things that you need to express and I highly, highly, highly encourage everyone to think before writing the first line of code what they need to express. We do have to do another episode at some point about serverless function because I have similar opinions and more than happy. Thank you so much. You have a good one everyone. Bye.