Episode transcript

Ryan Burgess
Welcome to a new episode of the front end Happy Hour podcast. Before we jump into the episode, I also want to let you all know that Jem and I will be traveling to Atlanta for a render ATL, we will be doing something special for front end, happy hour at the conference. If you would like to join us and are wanting to register for the conference, we also have a discount code, which is F E H. H, we hope to see you in person and maybe meet a few of you. It's been nice to get back to some of the in person conferences. In this episode, we're going to be talking about micro front ends, which there's been a lot of buzz around this one lately. I feel like it's been a long pole of bazoo. I looked up it's been around since 2016. But I felt like in the early pandemic, that's all I heard about was micro front ends. And it's actually really funny is I was invited to a clubhouse. Sometime in the pandemic when clubhouse was really popping. We were talking about micro front ends. And that's where I met Rubin, which is our guest of this episode. So Ruben, can you give a brief introduction of who you are, what you do, and what your favorite Happy Hour beverages?

Ruben Casas
Sure. So my name is Ruben cassis. I am a staff engineer at postman. And my favorite Happy Hour beverages probably. I'm in the UK, so it's probably a pint of beer, that will be the best one. However, I've been trying to get into whiskey lately, there is only one problem. And it's that I don't know anything about whiskey. So I ended up always drinking cheap, you know, Jack Daniels or something. So if you have any tips, let me know.

Ryan Burgess
I could definitely give some recommendations for some good

Ruben Casas
racing. That would be great. Yeah, yeah. All right. Well, one, it's

Ryan Burgess
it is just Jem and I as panelists today. But Jem, you want to give an intro Jem Young engineering manager at Netflix. And I'm Ryan Burgess. I'm a software engineering manager at Netflix. And each episode, the front end happier podcasts. We like to choose a keyword that if it's mentioned at all, in the episode, we will all take a drink. What did we decided today's keyword is? It depends. It depends on the keyword, right? Yes, awesome. All right. Well, as we dive into the topic, what is a micro front end? Let's start there?

Ruben Casas
Well, I have a problem with with the name. I mean, I have a problem with microphone tennis in general. But the name is really confusing. You know, when you say microphone, microphone 10s, you immediately think small. And you also might be thinking about, you know, microservices, which is partly true. But I have a problem with the name. And I also have a problem with the definition. So let's look into that. So the official definition is is an architectural pattern, where you independent, where independently deliverable front end applications are composed into a greater hole. Now, if I asked you to, you know, after I read that definition, is it is it clear? What am I micro content is what microphones are made, you know, is a bit confusing. So, and the thing that I've seen is that the people confuse the actual architectural pattern with the implementations or microphone tents. So long story short, it is an architectural pattern. And how do you achieve that? How do you implement that pattern? Well, you split your front end application into smaller pieces that are deployed and developed independently by different teams.

Ryan Burgess
Nice. That was a better description than I expected. Reuben. Thank you. That's very good.

Ruben Casas
You're welcome. But yeah, that term is no, it's not that great.

Ryan Burgess
It really isn't. Now, now you've seen that I'm like, yeah, actually valid point. Like, I never really picked out it. But now as you outline that I'm like, yeah, it's not the best term.

Jem Young
It's in there like serverless. For me. We're like, that's, that's not what it means. It sounds cool. But like, you know, the name is incorrect. Everyone, I like to call that it's an architectural pattern, not like any one thing you can do. And there's different ways of implementing it, depending on your definitely your kind of your view of what a microphone is when you're trying to achieve at the moment.

Ruben Casas
Yeah, that's right. And the problem with the TAM also is that people immediately think about microservices. And when you think about microservices, you think, oh, multiple languages and multiple frameworks. And that's one of the main misconceptions about micro front ends, and is that you can mix and match your front end frameworks, where in reality is not the case in reality is more about, you know, deploying your application independently and solving a problem. So that's, that's I mean, important key takeaway for today is, you know, it's meant to solve a problem. So if you don't have a problem yeah, you don't you don't need microphones. And so we go into the deep into why we need them and whatnot, etc.

Ryan Burgess
Oh, so you're saying we shouldn't just go rewrite our application just because we heard micro front ends are cool. No.

Ruben Casas
There are many options and microphone 10s. I think the reason also we are talking today is because I think James, so one of the diagrams I created where you can have multiple choices of architecture. So, you know, the most traditional one is the monoliths, and the Monolith is fine. I don't know why the monolith has so much hate. The Monolith is great. A lot of companies have been built and have massive monoliths, and they work fine. And for them, it works. They don't have a problem, or they seem to manage the problem better. But then, if you have a problem with the monolith, there is a scale where you can start like gradually improving your architecture, just to make things a little bit more decoupled. And then you arrive at the very far end of the scale is the microphone tense. But what people don't realize is that there are many different options in the middle that you can also try and adopt to see that solves your problem. The problem I have seen is people just go you know, zero to 100 from monolith, and then this go to the microphone tense, which is distributed architecture and is even, you know, it's more difficult, or more things that could go wrong. And he it doesn't even solve the problem. So if they didn't have a problem, you get more complexity. And then you're not even solving the problem that you had in the at the beginning.

Ryan Burgess
When it's funny, I honestly, monolith microservices, whatever it is. There's trade offs that happen like it's not like one is necessarily better than the other. It's to your point, Ruben, what problem are you trying to solve what works best for you. And I also like you said, Don't go to like zero to 100, you can kind of find what works for you and your team or your application, your company, whatever it is, what you're trying to solve, and then what works best. And also iterate right? Don't sign up for just being monolith and say the app that solves all our problems is like you kind of have to iterate and try and figure out what works best. But maybe that being said, I am curious to know, like, what would you both say like are some of the clear benefits, or even to Reubens point, what problem do micro front ends solve?

Ruben Casas
I was gonna say it depends. So I mean, the main problem is scaling. And it's not scaling in terms of your application performance, or infrastructure. Because that's probably the main difference between micro services and micro front ends, you know, like micro services you have, what you choose micro services, because you want to potentially scale in terms of horizontal scaling of your services, and the return infrastructure side of that. But microphone 10s, the browser doesn't, you know, you have one browser, you can split it into multiple, you basically your infrastructure is not gonna get better if you use microphone things, you still have the same back end servers that provide your front end application. But the benefit is more into the organizational side in micro frontends. So microservices have both have the organizational and also the infrastructure that you can, you know, increase your ports, and then you get more throughput of your application. Microphone things are, unfortunately, because of their browser only benefits on the on the organization and team structure side. So usually, companies try to adopt Mike front ends because they have a problem with scaling their teams. So a lot of people are working in the monolith, you probably have seen that before. When application starts getting really big, a little bit big. And then a lot of people start to make changes the same time and then deployments, rollbacks, bug fixes, all of that starts getting slower, slower, more complicated. So people start thinking, Okay, we'll independently deployable applications in the front end, help us with this. Will that help us be more, you know, go faster, deliver faster products?

Jem Young
It will? In the beginning? It seems like oh, yeah, microphones, our solution is because like, you know, all these teams have to talk to each other, it's much easier for them to just own their own repo, they'll talk to anybody, they don't have to coordinate. And Reuben, I love what you call it out there like that. We're about scalability. Like this is real. For those of you who are new out there, or front of happier regulators, this is more we think senior engineer, Architects like this, the level we start to think at which is, you know, scalability, it's not can my application handle, you know, X concurrent users, etc. It's scalability of your organization, scalability, communication, scalability of how your code works. And that's really what we're talking about monoliths get a lot of hate, because it's what people are used to, especially if you're coming from the Python, Django world where, of course, everything's a monolith, you know, people think because it's old, it's not as good as say microfinance. But monoliths scale really well, they scale organizationally, well, they're well proven. But let's say like microfinance have their place. If you're a fast moving startup, you don't want to pay the organizational tax of communicating between a bunch of different projects and a bunch of engineering scripts and opinions about code. It's much easier to silo them off and say, like, hey, oh, you want to do react over here? Cool, you can do that. You want to do a complete a framework over here, you can do that as well. But there, we can talk about this one, get the pros and cons. But yeah, there's no silver bullet here. It really is. It depends. And it depends on which metric he hears. And it really, it's about what problem are you trying to solve today? And are you willing to pay the tax on that later down the road? Because I would say microphones can get very expensive if they're not well managed. And that's, that's something we're starting to see now more as people have been using these for a couple of years, you start to see like, hey, maybe this wasn't the best idea as our product matures? Or, hey, how do we unify all these different code bases and styles into one? Because it's becoming really expensive to maintain all these different? Absolutely.

Ruben Casas
And you mentioned a couple of things. So the first one I want to get out of the way is, you know, the multiple framework thing, I do not recommend it. I'm like, please don't I mean, if you have company or not, cannot agree, using yours just react. I mean, you have bigger problems than you know, you don't. But basically, what I the reason I say that is because not just because of their performance, but the performance is the main one that people say, you know, if you have react and Vue and Angular, you have a lot of both, you know, their bundle, size gets increased, etc. But even if you fix that problem with the performance, you end up with a product with the organization, which basically you have 234 teams who have a different set of skills, and they use a different component library, you cannot do knowledge transfer. So I definitely say, you know, yes, it sounds really good on paper, you know, you can use whatever you want. But in practice from, you know, the companies I've worked with, and the companies I've been talking to, is a bad idea is a bad idea in terms of reusability of the code. And, you know, sharing knowledge etc. So, if you have a use case, I have two, only to use cases where using multiple frameworks might be a good idea. One is if you're migrating. So if you're migrating, let's say, you know, you had AngularJS, and you want to migrate to react, well, at some point, you will have React and Angular operating on the same page. And thus, basically you cannot avoid that. And there is a pattern called the strangler pattern, which basically you remove the old application, and then you put the new application on top. So that's one one exception. Another exception is, oh, there is a company, there is an acquisition, you know, they bought a company and they have their own, you know, framework or skill set, Microsoft front ends will help you run those two different technologies at the same time. But at some point one has one of them has to give way, you know, one has to adopt the new framework or not. Or you might stay with them. But those are the only two cases that I I'll say, use multiple frameworks, with microphones. And that's the biggest myth, like, you know, people think microphone 10s equals multiple frameworks. And I've been trying hard just every time I, you know, talk to people like, No, you can, but the fact that you can, doesn't mean they you should, so

Ryan Burgess
no, I like what you said to Ruben that it's like, if you can't decide on a framework as a company, then that's, you know, you have your own problems. Granted, you know, there are large companies where there might not be a reason to decide on one to rule them all. Like, you'll have pockets of applications where they'll be written in one and, you know, application and the other and I think that's fine. But when you're trying to ship to the same customer in the same application, that's where it's really problematic, like you said, with the Bloat into the package, like that's no good. But then also just reusability, too. It's like you shouldn't be able to share components, you should be thinking through that and like collaborating in that sense. And so yeah, I agree with you wholeheartedly that that is not what micro front ends are for. I'm glad you said that. The only time when I'm like maybe it's okay as if you're trying to migrate to another framework, right? Like because we've all been there, migrations are tough. That could actually be a way of doing that. We're like, Okay, we're going to slowly migrate to react or we're going to migrate to view

Ruben Casas
on microphone. Things are great for migrations. So one of my favorite use cases is migrations. Because, you know, today you can't just go to the business and say we are not going to do any more features. We are going to do a big bang rewrite. The only thing you got until the Big Bang rewrite is a big bang. So that's. So basically, the microphone 10 story for migrations is okay, you don't have to do a big bang, rewrite, you just incrementally rewrite your application. And at the end, you end up with a brand new application that is more composable. And he has more flexibility. So migrations is my favorite. You know, apart from the token, again, we were talking about the benefits, you know, benefits are organizational improvement in steps of agility and deploying independently. But also, migrations is a great use case. For microphones. I think,

Jem Young
just like zooming in on the granularity of microphones, because it's still kind of a vague term. One thing I've seen is you have a page on any website, that could be actually be a microphone, and where like, the header and the footer, and then sidebar, are all different teams that work on those in different parts of the feed, I'd say Facebook's a great example of that, where you have the homepage feed, you have the news feed, I don't have been on Facebook in years, but like you can have that sort of architecture in a single page application, where it's actually a bunch of different applications composed together, then you can also have a microphone and where every page, or different parts of the pages are different teams with different applications as well. So it's really it's still that really vague definition. But as some of those some of the like some of these give me the heebie jeebies, because like I just see the complexity exploding if it's not well scoped. And that's some of what you're talking about with microphones like being good for you. If your company gets acquired, or you're trying to do a migration? Can we talk a little bit about the cons of microphones? Because I'll be honest items being really candid, I'm not a fan of them. I think they have their use case, but I think it gets abused sometimes. But we'll talk about that a bit.

Ruben Casas
There are a lot of cons. Actually, I have a talk just that's title, you know, the risks of microphones, because I have seen them firsthand when they work. But I also have seen them firsthand when they don't work, and is a is a mess. Before before we get into that, you know regarding how do you split them? Because you mentioned you know, there are small there, are they a page. The key is business domain, I think you touched on really briefly there, you know, you don't think about is this micro frontend, a page or a component, you think who owns this part of the application? Who is the owner? Why is my business domain map to this part of the application. Because one of the cons of micro front ends is that people slice to granularly. I then and they end up with too many microphones. So that is probably one of the first one is, you know, you go crazy. And then you split your page into 100 Different applications or different microphone tents, down to the component level. And guess what that means? That means that you have 100 things to look after, and tons of things to deploy and 100 things to maintain. So increases the complexity. So I'll say, Do not crazy, go crazy, you know, splitting microphone tends to granularly. Think about business domain. Think about team who owns it and think about you know how that maps to your business. Going to granular to the component level is probably not a good idea. I haven't seen any cases where it's actually a good idea to go into the component level for that you have a component library, right? You know, that's a standard component libraries are great. So microphone, things are more like a collection of components that map to a business domain. So number one is, you know, too many microphones, tents, too much complexity, that's probably one of the main reasons why you shouldn't go to microphone tents is obviously it's a distributed system. And a distributed system requires more maintenance, it requires more, you know, maintainability, I don't know, it requires a lot of stuff that you have to do to make it work. Whereas before, it was just simple. But the reason people go there is because Okay, larger, larger organizations, they have the resources. So there is like a balance between, okay, what the additional complexity that I'm introducing, is it worth that complexity, plus the benefits that I'm getting out of it, which is, you know, going faster. And my application can be more reliable because I can scope and fix errors. Make sure that I'm not introducing bugs when you know, though I'm not deploying the entire application basically. So yeah, that's one of the cons is too granular. And I have seen them, I'm going to tell a story, actually. So when I used to work at my previous company, one of the senior engineers came and they were like, I hate microphone tennis. This is a bad idea. sat down with them. I was like, okay, hold on. What's what's going on? Well, when we used to have a monolith we use just deploy the application once. And that was it. Now If I have to plan my releases, and then have to plan five hour blocks for my release, I was like, hold on, what five hours? Why? Well, my release is taking five hours. I was like, okay, that's not right. Why? Well, we have 70 microphones and seven zero microphone tents for this page. And we have to the flow one by one. And if we deploy them out of order, like if we deploy this one first, and then that one, then everything breaks. And we have to roll back and do it again, I was like, that is the opposite like the complete opposite of what this is about. Because we are going to talk about something else, which is the the key is coupling. So for for a distributed system to work. And for a system to be distributed, you need to decouple it. Because if you don't decouple the system, you end up with a distributed monolith, which is the case the story I just told about my colleagues, that was a distributed monolith, because they had to deploy everything, all these granular pieces, at the same time to get a coherent UI. They were not getting any benefits from microphone tents. So I think the key is coupling like people distribute the application make it independently deployable, but still coupled. And then they still have to deploy everything. Like in sequence, which is probably the worst of both worlds, you know, the monolith and distributed systems.

Ryan Burgess
I also like the said about the complexity, because that wouldn't always to me hits the top of the list, microservices, in general, or micro finance doesn't matter is that complexity. And something that I think about even really, specifically to micro services is the sense that you one benefit is you get to really focus, right, like you're working on your feature or or your page or whatever it is, you have that folk but the problem is, is that now everyone has those focus moments, and that there's not really an understanding of the whole entirety, right. I'm sure there are some folks that do. But it breaks down more and more. And so communication has to be really great. And I think that that's something that it's not a bad thing, it's but it is a trade off that you really have to figure out is knowing that complexity and having a good understanding and communication line with the team next to you or engineers. Next, whoever you're working with, where those dots connect, I think that's a big piece that always comes to mind. That can be really hard.

Jem Young
Yeah, I'd say like I treat the software engineers, like, you don't get rid of complexity, you can abstract it away. And you can change who focuses on it. But like, it's always gonna exist in any given system. The challenge of micro friends is primarily around complexity. But to casual friend engineer, you don't see it, like you said, right into your heads down, you focused, you have your repo with, you know, 510 20 other people on it, you don't worry about everything else. But Ruben, like the story you're telling, there is a team that has to worry about how it all comes together. Usually, that's the sometimes the SRE or deployment team or whatever you want to call them at your company. Somebody's worrying about how all these pieces come together. And when they don't come together and they won't. Plenty of times somebody has to deal with that. Now, is it better for some team that's kind of abstracted away from actually working on the code, the salt that or is it better for the engineers themselves? who are writing it to help navigate how these components talk to each other? And like, right, I like to call out there like it's about communication. And that's, that's kind of key in any company is how did the components talk to each other? How do they communicate how these teams communicate? The great thing about microphones is like, you don't have to talk to each other necessarily. The bad thing about microphones, you don't have to talk to each other necessarily, like that's a problem. And it's totally irrelevant. Or it's totally based on your business in your organization. Like how well your communication lines are set up.

Ruben Casas
Yeah, how well your organization can can do that how well you can go without talking to another team. So to answer your question, was how you handle this? Well, it depends choose. But the you need a platform. That's what I call a platform or like, like a platform team in a company. I used to work at AmEx and AmEx, we used to have the platform team who was in charge of the like the framework where all the teams come together and use that framework to build it. But your use, you need some governance, you need someone who knows how everything comes together. But the success of a good platform team is that they have the the rails for teams to just forget about the architectural side of it. And they just focus on on the features, and then deliver their features with great tooling and great libraries to support that. So definitely, if the company is big enough anyway, you have a platform team. And that platform team usually is like a subset of you know the people who maintain the design system, people who maintain the architecture Neural infrastructure, all of that. So you need someone looking after the whole picture. And in terms of in terms of communication, I mean, I'm not selling these very well, I think I need to sell it, the more benefits of micro front ends. So basically, when you have, you know, the developer experience is a good one, because you don't have to think about the entire application, you just have this small set that you can just develop, but also isolating errors. I think that is probably one of the benefits that is not talked a lot about microphone tents, and is that if your application is decoupled very well, you can make sure that you isolate those errors, and you isolate the failure. So if a microphone 10 fails, then you don't take the entire application down. That's one side. And the second part of the failure isolation and error handling is, if you deploy the entire application, then you don't know while you are deploying, you might be deploying a bug that you're not sure about. But when you're deploying an application independently, then you know that you're only making changes to that particular application. And that shouldn't make any difference to anybody else. If he's decoupled properly, like it shouldn't introduce any problems. And I think one of the reasons people don't like the Monolith is basically because of that, because you have to deploy everything at once. And if you break something, then the deploying rollback or hotfix is very challenging. So we microphone 10 is just basically I just deployed my part of the application, there is no strong contract, where I know that I don't write a contract similar with microservices. So I know, this is my space, I don't get out of these boundaries, and I will be fine one that

Ryan Burgess
made me just think of it too is like, it may be seem minor, but can be a big one, when you're ramping up on a team or anything is pulling the codebase. Like when it's a monolith is massive, right? Like, it can take so long to get up and running. And especially or if you've gone on vacation, or you haven't touched the codebase in a while. Sometimes that can, you know, be a lot to catch up on. So I think that that in itself too goes back to that focus where a micro front end is like You're like I just focus on this. And so there's less changes in that scenario in that little space, too, which is kind of nice.

Ruben Casas
Yeah. And if you're going to a code management part of microphone tense, a lot of people don't like microphones, as well, because of that, because you have a separate repository for everything. Yeah, that's good. If that was a good case, you know, I can just focus and I can just pull my repository. But the other side is in terms of going back to you know, the cons is like, you end up with too many repositories, and that is going to be difficult to track. So what I've seen lately is that mono repos are really good as well for microphone tense. So people think, Oh, you either do a mono repo or micro front ends. But actually, you can combine both. Like you can have really good mono repo tooling these days. It didn't used to be the case like five, four or five years ago. But today, the tooling for mono repos has gone panics. And actually, one of them is called NX. I love NX is really good. And auto repo, they are really good mono repo tooling that you can use today. And that can help you to get benefits of independently, deployable, epic, epic applications. But also you don't have to clone 10 repositories, you just have the mono repo. So the code organization aspect is not really the key here. The key here is decoupling. So in a mono repo or a separate repository, the key is that you have that microphone 10 is very separated, separated from the rest of the code base and the you know, where everything is coming from. So you know, the inputs and outputs from that particular section of the application. So I think that's the benefit, like decouple the application more than all the other benefits, you know, like, independently deployable applications, etc.

Jem Young
And Netflix right now we're using more of Ruben, I think you call it a modular monolith, which I like, and we're moving towards the integrated application. So that's like stuck on exists within one repo. There are different applications and different teams that work on those. And they're deployed independently. So they actually don't talk to each other too often, other than through API contracts and things like that. I agree. I think it's a sweet spot, especially it's based on everybody else. I like to call it platform team. Because you know, I leave the platform team. So I care very much about this topic. And this is something you know, we spent a lot of time thinking about, it's about like, one how well funded is your platform team? Is it a 20 person platform team? If so, you can afford maybe to dive into microphones a bit. If you're running on a smaller platform team, we run a bit more lean. You have to think about that efficiency that what's the scope of that platform? What can they actually pay attention to if you run into an issue, can they help you solve it or not? So like, you know, we're talking about COVID Talk about architecture, but really comes down to like business and organization. And that's what all this is reflection of is your organization.

Ruben Casas
Yeah, absolutely. And obviously, if you want to take more complexity, you need the resources, the success of a platform team is that they need to absorb all that complexity and lead the product teams develop, you know, freely with everything they need. So the platform team are basically taking the toll of the complexity side, you know, they are the ones who need to create the correct abstractions, they need to ensure that everything just works. And that's what I used to do. You know, on my previous job, we had everything, people just had to basically start a command, and they will have everything for them to start developing their own application, they didn't think need to think about infrastructure, they need to think about how he composes into the page, nothing. But then it was up to us, the platform team to create all those abstractions, and hide all that complexity away from them. So yeah, you definitely need a well funded one. And he has to be, there is a really good concept that I love. And so, there is a sense of urgency, you know, like in organization is, you know, you never get this, you know, we do later we do next quarter next quarter by there is a problem, you need to pour resources and then create like a sense of urgency to Okay, we are going to do it, we are going to implement either microfinance or micro services. And we are going to put all the resources to make it work. And, you know, sort out the complexity because we know the benefits are going to outweigh that complexity,

Ryan Burgess
we're going to in your current role, or you use micro front ends,

Ruben Casas
micro service micro front ends. So we are using micro front ends right now for migrations, because as that like the main reason, and what we have done is another really good concept I love is reversible decisions. So in my architecture, I don't have to go all the way to microphone 10s, I have to I can choose. So basically, we have the monolith. And if you want to deploy with a monolith, fine. But if one of those applications was deploying dependently is a very easy switch. And then they decided actually deploying this independently was causing too many issues, then we can go back to the monolith and then go with the release rate. So we are creating a more like a decoupled architecture that you can deliver independently if you want. But if you don't want to, because you don't want that complexity, you can go back. And the second part of it is the migration. Like we have a really old application, we want to migrate to the new one. So we're just taking piece by piece, from the old one to create it as a new brand new architecture.

Ryan Burgess
Nice. Yeah, because I know hearing jam talk about like how netflix.com is set up? If you go across Netflix, there's lots of different approaches in different applications. But I was curious how you all were approaching that. When I when I think of micro front ends, too. Is there like a good library or framework that lends well to micro front ends? Like I know, we mentioned like, yeah, you can technically use a bunch of frameworks and throw them all together. But are there some that lend better to it? Well,

Ruben Casas
I think frameworks these days, you know, like React, they're really good at composability. So you can actually split your application into components and then a collection of components. So that took us like closer to that composability decouple thing. Now there is one key technical aspect about micro frontends. And if you go to what I call runtime composition, micro front ends, which means that you you are on the page, and you don't need to redeploy, you just get a new update, when they use as refresh the browser, they just get a new update. That's what I call runtime composition, which is you don't need to build and deploy, users just get updates over there. For that one to work. There is a piece of technology called module Federation, that is really good, just basically loading JavaScript at runtime. So that's one of the frameworks for single page applications especially is really useful. But there are many ways of composing microphone 10s. You know, I mentioned client side composition. But you can do that on the server side as well. Or you can just do templating on the server side. And then get the microphone 10 source code from another service and then just rendering on the server and then send it to the client. There are edge H like using the edge today is like bells word by microphone 10s, you can use that as well, you know, before the user gets the page, the Edge server will just take it and then compose everything and give it to you. So far, the one I been using the most is client side because of single page applications. So that's probably I'll recommend is probably also the easiest, because server side is a bit more complex. And again, we are talking about complexity then when you want to get rid of as much complexity as you as you can for you to see the benefits.

Jem Young
I think one piece we left out was with microphones you're assuming one team works on one repo in one area of the code. What if you have to work in multiple parts that means you To build multiple repos and multiple people's code, and there's not a centralized way of building, which sometimes there's not sometimes everybody, sometimes some people might use, I won't go into all the tooling. But you know, different teams might have different commands to run things, then you're running like it's even more complex in the long run, if you're, you have that sort of organization. But again, like it all boils down to like, what sort of development are you doing? What sort of product are you building? What does your organization look like, because you can make it work. But something Oh, I'll say something as large as like our Netflix web team, it wouldn't work, it would be so complicated to have a bunch of microphones and people having a bunch of different ways and opinions on how to build things that working on multiple projects would be a hobby, a nightmare. So you can tell the platform team because like, I just, I'm like, Ah, complexity,

Ruben Casas
this is another thing about microphone. 10 is like people talk about them. But the people who are actually using them, don't talk a lot about them, you know, you'll be surprised how many large companies are using micro frontends. in production today? Again, going back to you know, the success of this, is it solving a problem. If he's not, if he's gonna cause more problems is going to solve them, then yeah, avoided, absolutely. Just don't get near it, because it's going to cause more problems. But the tooling is also been, it's helping with all this complexity issues that you just mentioned, you know, like, if a team wants to build this, and if I have to build all the repositories, is incredible, the way that the tooling helps you, for example, just pull their production website, you don't have to build anything, you just build their production website, and then your repository or your small micro front end is I think that you change, and everything is working fine. So there is also tooling that will support and will fix those problems. So yeah, I mean, there is a difference, there is also a fix for everything. So your company choose

Ryan Burgess
what are some tools, Ruben that you've found have found useful for that.

Ruben Casas
Well, if I was gonna say depends, again, but we just had, if you're doing client side composition, there are there are many ways there are like tools that will basically map all your microphones that you have like a dashboard, where you can just toggle them. This is another benefit. Actually, I forgot to mention a B testing, or you know, that for microphones is also good, because you can with microphone tends to switch between different versions or runtime. So you can run really cool experiments. And tooling, in terms of tooling, there are like dashboards, where you just basically control what is active on the page at any given time. And it's really cool is, it's actually scary, because you can get into really complex, you know, chaos engineering, if one of the fountains failed, then the next one will just come up automatically and stuff like that. So you can get really clever with this and you can make really cool stuff. But again, if that stuff is distracting you from the main goal, then don't look into that, you know, the chaos engineering, you need to be really mature with the basic concepts, or microphone tents and distributed systems. Before you can go into all of that, you know, self healing, chaos, engineering, ABX testing, all of that stuff will be more like on top of it once you have achieved all the benefits of the coupling. First, the different stages, you know, met Jem mentioned the modular monolith. I think the key distinction is when you deploy independently. So if you separate this problem into two decoupling, like if you decouple your application, you'll end up with a better application because you are not stepping on each other's toes, you're not making changes are going to break something else. And then if you go a step further, and you can distribute the application independently, then you end up in a microphone and architecture that might give you some benefits. But even if you're not going to distribute independently, please decouple your applications because the most of the problems have seen out there is spaghetti code, you know, like you end up with, nobody knows why is where and it's very difficult to make changes because everything is here and everywhere. So I like pasta, you know, I like a good carbonara. I don't like spaghetti code. I prefer this. Like, I prefer to call it a pizza, architecture, you know, pizza, you can have a whole thing but you can get a slice. And then you know, I prefer to prefer pizza to pasta actually, in terms of architecture. So decoupling is your avoid past just make sure you can slice your pizza correctly into smaller pieces. And if you want to deliver independently world that is a decision that your team can make. If you want to take again the complexity. I feel like we should have picked complexity as the cheers for keyword.

Ryan Burgess
But it comes up enough Yes.

Ruben Casas
But um, but yeah, is decoupling is probably If you're looking into this, if you have a problem list, start decoupling your codebase, then study coupling your application, and then decide then, do I have to go? Do I want to go to the far end of the distributed system? Or is a decoupled modular monolith enough for me, which could be a mono repo, or it could be just a normal modular monolith. So, yeah, that's probably the thing I wanted to say at the end.

Ryan Burgess
Awesome, which makes a ton of sense. Well, it's probably a good time for us to jump into pics. In each episode of the front end, happier podcasts, we love to share things that we've found interesting want to share with all of you, Jem, you want to start it off?

Jem Young
Yeah, I've got two picks today. The first one is a book by Sarah Dresner, who is a free semi frequent guests on the show. She wrote a book called engineering management for the rest of us, I highly recommend Sarah, throughout my years of knowing her has just given me pearls of wisdom here and there without even intending to just say, like a great leader on the round. So I really respect and you wrote a book about management. I really, I know, ICS will probably are software engineers will probably not read management less. But it really is worthwhile to think like, this is how your manager sees the problems you solve. It's not necessarily about the code. I mean, it always comes back to the code. But that's one aspect of it. And I think everybody be a little bit better off if we understood like how managers think about things I wish I had known, like years ago. So highly recommend the book. My second pick is Valley silicon pic. So normally, I do a whole bit where I'd say how much do you think this will cost? Would you pay for it? But this one, I don't know it. I'll just describe it for you. It's a food processor, or it sells itself as a food waste poster. So you're like, Oh, that's a good idea. You know, we should compost our food. A lot of people have noticed a lot of greenhouse gases are caused by just food waste getting dumped in and they break down, they released greenhouse gases. And if we can post it our food, we just kind of shorten that cycle a little bit. The reason why the loamy food and waste composter is Valley silicon picked because I remember coming across a YouTube video. And it was like, What is this thing actually do? And like how does it compose food like faster than just normally like putting in the garden and burying it and let nature do its course. So what it does is it heats up all of your food, and he eats a really, really high and then it cools it down and that helps it break down. But in doing so it becomes less environmentally friendly than just like simply bury it because it takes so much power to do that. Then it kind of defeats the purpose of what it's supposed to do in the first place. And not only that, you have to chop up your food yourself and then put it in there you can't just like double down appeal or something like that. It'll get clogged. So I picked this because it's a $500 kind of heater for your food that maybe in the long run probably isn't as environmentally friendly as as a man's put it but if you have one good to me, Jem Young you could disagree with me all day. I'm I'm here for your footer arguments.

Ryan Burgess
I've seen this before and I thought it was to make it like yes, better for the environment. So okay, you're saying no. And then another one is I thought it was like to prevent some of the smell. And that it was easier. I'm sorry about chopping up your food to have to no like I don't think so. I compost it's I do it all the time. But you know what, I throw it in a tin into the bag. And when it gets full, I empty it. I don't know. That's hilarious. I would have expected it to make my life easier. Not harder.

Jem Young
Yeah, it's one of those like, it looks cool. It makes you feel better about the like doing something for the environment, and it's really expensive, but in the long run. It's not really doing a whole lot. It's not doing what you think it does.

Ryan Burgess
That's amazing. All right, Rubin. What What kind of pics you have for us? Well, I

Ruben Casas
have probably let's do three. Let's do one resources for microphone tents on topic. So I recommend the book by Luca mozzarella. He's a good friend is building microphone tents. So if you're familiar with building microservices, he wrote the book for microphone tents. So 100% recommend it. And also my friend Italia vendita. She created a website called microphone 10 dot Dev. She basically compiled a lot of the microphone 10s architectural decisions and not just about microphone things actually he has a lot about frameworks as well. So definitely shout out to both of them. And in terms of two more big so the first one is series The Last of Us I've been watching it and it's just amazing. If you're not watching it's just he's on HBO so it's not Netflix but is so good. I've been I play the games. I've been just blown away but this series is so good. So visually, you know, is amazing. So take a look at it probably a lot of people are and the last one is probably that's probably going to help gyms pick Actually, because you said that he's gonna use energy. So I recently got, I want to be more environmentally friendly. And also, well, it's very expensive in Europe, the current crisis with energy. So I go solar panels and a heat pump, which is any device that is like an air conditioning, but works in reverse, to, you know, lower your energy bills and be kinder to the environment. So I'm pretty sure that if you plot your food processor into my solar panels, then it will be free energy. I'm not sure about the gas, the greenhouse gas that we produce, but anyway,

Jem Young
I also have a heat pump. We got one last year and it it is great. There are downsides to like it doesn't work if the ambient temperature is like too low. But it still takes substantially less gas than our general like power than my. Yeah, so I'm a fan of

Ruben Casas
it. Yeah, it doesn't really get cold that cold in the UK. I mean, the UK is where you were if you go below freezing. So he kind of does the trick here. So

Ryan Burgess
all right, I have to pick I actually have three picks. I'm going to stay on topic. I'm going to share. You know, Ruben, you had mentioned the risk of micro front ends talk that you did. So there is a video on YouTube highly recommend going and checking that out. And then I have two picks for two documentaries that I've watched both very recently. And I think it was like one after the other. I went down a rabbit hole on collecting apparently. So the first one I watched was on Netflix was it's called the Pez outlaw. So it's this whole story about this guy. I mean, there's these people who collect PEZ and it's like this big thing. The Pez outlaw goes and gets ones that aren't available in the US and he starts selling them. It's this whole thing. It's a cool story to kind of follow the like community around people who collected PEZ and then this story of this Pez outlaw. So had follow up on another collection show in the 90s was Beanie Babies. So there's a documentary on HBO called beanie mania. And it's all about the craze of people collecting and selling Beanie Babies. And it was really interesting to kind of learn about the company selling them. And then the like secondary market and how it was almost like this fluctuation of stocks almost around Beanie Baby values. It was an interesting story. And I remember a lot of this growing up, but to really see it, like pulled together in a story it was it was really interesting. So I highly recommend both those documentaries. I don't ask me why I got down this rabbit hole. I'm not a big person to collect things. So but it was interesting. So yeah, those are my picks both really good. Thanks, Rubin so much for joining us on the episode. It was great diving into micro front ends. Where can people get in touch with you if they want to talk more about micro front ends?

Ruben Casas
I'm fairly active on Twitter. I didn't get my username. So my username is a bit strange is in foxy cater, but we the because the T one is now available. I've been trying to get that one for a long time. I don't know. Anyway, we just put a link in the show notes. And then also, I'm trying to use LinkedIn more on my website, I need to update my website as well. Keep getting traffic I because I like to write as well. So I like to write blog posts about front end architecture. So that's basically I'm deaf to writing a lot pretty much every week so you can find me there as well.

Ryan Burgess
Right on. Well thank you all for listening to our episode. You can find us on Twitter at front end each age. You can follow us on really anything that you'd like to subscribe to podcasts on. Find us at front end happy hour.com Any last words complexity? It depends. Chase cheers