Micro-frontends === Natalia: ~Six. Yeah, let's just reconnect, I hope.~ Paul: ~Test, test, test.~ Natalia: ~okay, how do I do this? Oh, you, I can do it with my phone as well. You want me to do this? Okay. Okay. Let me, let me. Voice memos. Okay. All right. Test, test, test.~ Paul: ~Test, test, test.~ ~Awesome.~[00:00:00] Hi there and welcome to Pod Rocket, a podcast brought to you by Log Rocket. Log Rocket helps software teams improve user experience with session replay, ever tracking and product analytics. Try for free at logrocket.com today. I'm your host Paul, and we're thrilled to be joined with Natalia Vandito. Natalia is the principal program manager at Microsoft, leading the end-to-end developer experience for JavaScript and no JS on Azure. Natalia: Hey, thank you very Paul: a Google developer expert for Angular and web technologies. For in general, we can talk about anything web development related and in a jury hero's inclusive hero. Today we'll be discussing micro front ends, a topic that Natalia's passionate about and has even created resource at Micro Natalia: Yeah, I'm located out of Barcelona and Paul: the benefits, best practices, misconceptions, and you know, talking a little bit about the architecture Natalia: rain. Paul: and why behind micro front ends. Welcome to the podcast, Natalia. [00:01:00] I am fantastic. I mean, when we're doing this recording here today, I'm located in Boston. We have freaky, freaky weather. It's usually 50 something Fahrenheit, and yesterday was what, 84. So we're all feeling good. I hope you're fantastic. Uh Natalia: Yeah. Paul: oh man. I've heard. Uh, so yeah, today we're gonna be talking about micro front ends Natalia: controversial part Paul: like one of those things I would Natalia: is not a one single Paul: jam stack. Somethings of somethings. But I know there's like Natalia: to agree with. Paul: that that's a mis that's a misconception. There's a whole Natalia: Yeah, and, and I think that's good because Paul: haven't Natalia: in the end, Paul: dev, or they've never like stepped into this Natalia: You have to find out what a micro front end means to Paul: that in some sort of like traditional [00:02:00] sense about what, I don't know what a component, I don't know what the best thing to relate it Natalia: experimentation. That's, that's what I suggest folks do, right? For some people, a micro front end may be in the sense of architecture, it may be a whole vertical split, which is you go to a URL and you're loading an application, and that whole application is a micro front end because it's developed, it's maintained, and it's deployed. And released, of course, by a uh, team. And for other folks it may be just a single button that hits a webhook and it's maintained end to end by a team. And it's also deployed independently from the main application that hosts it like the Shell. And so they both fit the criteria of being a micro front and in a. When [00:03:00] both components have a very important, let's say, front end component and, and by component, I don't mean like just one single component. I mean the whole concept of component. So yeah, what is a micro front end? It'll very much be, um, Defined by the context. Yeah, absolutely. Yeah, I think it's okay. You have a, you have to have I [00:04:00] ui Paul: I, I love that because I, I remember when I was in, uh, studying my Natalia: You're working on something that Paul: computer science, I was like, what is the front and what's the front backend? It's like every, everything's a front end and Natalia: a end user Paul: about your point of Natalia: or it can Paul: and your scope. And is that kind of what you're saying here is like a micro fronton? Really depends on what is your team and your application like. Is a micro fronton more like a meta idea about Natalia: but then again, what do you have behind that ui or what is it connector, connecting or integrating to? Is it part of that micro component? Or not for me. The, the, the, the one thing we have to look at is the team that is working on it. And I want to myself, I am trying to move away from that term, even though I, I have this domain, micro front and that dev, I have it because I know that folks are going to be searching for micro front end. And so it's kind of an SEO [00:05:00] strategy. But I, I am even suggesting in this website, in this, um, Collection of resources that people try to move away from this micro frontend term. JavaScript and HTML and c s s JavaScript, of course, yes. But HTML and c s s on its own may not be able to do a lot of the things that we're trying to do today in web development. So we we're going to have to, uh, environ move a little bit farther down the stack and. When you are trying to build a micro component, you're going to have a, an integration from one end to another. And it's ideal that the same team is responsible for the whole thing, like, um, the ui, but also the a p i and the what, whatever the logic is executed, the deployment container. [00:06:00] Not necessarily a container in the sense of a docker container, but wherever you're going to drop that, um, development artifact too. And, um, and yeah. And then the pipeline between the development team and that container precisely, that makes it possible to continuously integrate changes and so on. Yeah. Absolutely. Yeah. Yeah, absolutely. Paul: It's fast. We're talking about fast iteration. I, it almost feels like we're talking about a [00:07:00] people problem here. We're talking about reducing friction in between teams Natalia: And I always Paul: the smallest way that you can eat that bite with one Natalia: The reason why I Paul: go one Natalia: acquainted with micro front Paul: the Natalia: was because I was working Paul: get ready to build that a p i. Yeah, and I mean like a micro front end for a small team could be the. Natalia: pm uh, reach out and say, we need a blog capability Paul: and I love what you just said, cause now I'm really Natalia: and so it has to be deployed yesterday. And we were like, uh, we have to create the components. We have to create the APIs. And then we realized maybe we don't have to do this in the context of this very large application and wait three weeks iteration to have this deployed. If it was necessary to be built yesterday, then we can do it as an independent. Deployable unit, and this is when we started trying to explore where we can deploy it, how we can connect it, and how we can make sure that, I don't know, a [00:08:00] user, he in one part of the application has the same state as a user everywhere. So federation and all these, uh, things that. Kind of give it, um, some, some sort of consistency to the experience across the many parts. Right? And that's, that's, uh, how I started thinking about micro front ends more and more, and these independent, deployable units that make life easier organizationally. And also for the business units behind all these applications to. Yeah, to get their, their features delivered, uh, at the times they need them, right? Some, some, some parts of the application may not need so much development, maintenance. Some others are more like dynamic and need more attention. So it's a way to kind of separate concerns.[00:09:00] Paul: Now, I'd love to get into how you think this is affecting the industry and you know, teams at an enterprise scale, because there's ways that this is baked into. The way teams in HR is built from, you know, years and decades of doing this. But before we do that, I'm just gonna take a quick pause, uh, to once again remind our listeners that this podcast Pod Rocket is brought to you by Log Rocket. And if you're working on different teams like we're talking about now, where you have like, You know your API team, your backend [00:10:00] team, and you wanna start to conglomerate that and you wanna have more control over, you know, what are the backend calls and network calls do, and you wanna extend your developer tools. Log Rocket can help you understand exactly how your users are experiencing your web application and your digital product. With session replay, ever tracking heat maps, all sorts of great AI surfaced analytics, and you can solve user reported issues. Find those issues faster and. Conversion and adoption into your stack or application to Tri Flog, rocket to the today. Um, but yeah, I'd love to talk more cuz you mentioned siloing and how like you're, you're having this department, that department, and every big company I've ever worked at, that's exactly how it is. Like I've worked on a backend team or a front end team and if I'm talking, if I were to say, Hey, I have a microphone. Concept, like, I wanna build out this feature. I think we can boil it down, whittle it down to these three things, and Natalia: Yeah, I think, Paul: group of three people do this, this group of three people Natalia: 20 years ago, this Paul: this is the big main feature. So they'll just focus on Natalia: how Paul: I feel like I, I would be [00:11:00] laughed at sort of, it's like, no, we don't do it that way. Natalia: front Paul: so as somebody like yourself who's coming in and like pushing Natalia: was like, relegated Paul: you know, you're blogging about this, you're creating micro front ends, what's sort of. Natalia: painting layer on top of everything and Paul: you know more clearly paints the picture that I was just talking about. And how do you overcome that Natalia: But today we are moving a Paul: new way of Natalia: of. Logic and the experience, which is not necessarily good sometimes in terms of performance, but there is a lot more happening, um, a a lot more interactivity, a lot more, um, need for reactivity. And so some parts of the application may do have those needs. Some others are more static. And this is, this is the first thing you have to, to think about, okay, how, how can I split my application, uh, in the sense of what needs to be released earlier, what needs to be released not so frequently? And then this is how you separate the [00:12:00] teams and that gives you the opportunity to allow people, uh, smaller teams of people to make independent decisions. Try new things in parts of the application and it allows you to foster innovation in a sense, and, and even reduce attrition. This is something that I see that many people don't think about, right? Many times we get bored as developers, right? Because we are working for years or months or whatever in the same. Or with the same technologies. If we have this kind of separation of what we do and how we do it, and we are allowed to even rotate between teams and get to experience many different technologies and play, play with them. That's very cool. From a developer perspective, of course it has a con, right? It's the learning curve. It's the um, How do I [00:13:00] enforce certain patterns and conventions and make sure that they are kind of consistent across the whole application? Because learning a new, a new technology, um, it's one thing, learning a new way of doing things, uh, as part of a team is another right. And so for me, there is one thing that is non-negotiable and it's governance. Governance a a layer of governance on top of this. Uh, whole development, um, split, let's say even the teams and the application as a whole, right? That, that then you're putting together those mini components or micro components that then you're putting together. There has to be some kind of a ruling that says, this is how we do things. So even if you move to a different team, we're going to be following certain conventions, so it's easier to integrate. One way to do this is to have a. [00:14:00] An API contract, right? So we are all different clients, but when we're connecting to an api, we're going to do it in this way and. At the same time, the teams that are in charge of the APIs know what they have to deliver to each team. And yeah, and this is how we prevent spaghetti and technical debt and all these things. But again, the, the, the benefit, the real benefit from this kind of, um, breaking apart the teams into many, um, or into multiple teams is to allow. Uh, folks to bring their own ideas and experiment, explore, and grow different parts of the application in different ways. The orchestration or the putting all those parts together continues to be and will always be very, very difficult. And this is why tools like the one you were mentioning, uh, low Rocket, right? Uh, they are very necessary to have some sense of, [00:15:00] um, Visibility over what's going on, like observability, analytics, um, making sure you have insights at all time of, um, the application as a whole. There has, there has to be a certain layer on top of everything that kind of solidifies and consolidates, uh, the integration and, and that's how you succeed in the end. Yeah, exactly. Yeah.[00:16:00] Paul: Yeah, I mean, governance and orchestration are, you know, you pointed, you pointed those Natalia: Yeah, absolutely. Well, I, I, um, I'm a proponent of API Paul: we're gonna sort Natalia: so for me, the way you go about, Paul: my, my mind immediately goes Natalia: an architecture perspective is you get the designs, the Paul: Okay. So you say, I was gonna expect you to say that's specific, that's too specific. Like you're getting into the weeds already and. Natalia: and then you only, then you Paul: interrupting the flow of other people's, like micro Natalia: on each side Paul: but so, so you're saying No, that's a good place to start. A swagger doc. Okay. Natalia: Yeah. Yeah. But, but it should be also, um, a collective exercise. Right. Everybody should be, um, kind of, uh, invited to [00:17:00] give their perspective. Not every member of the team perhaps, but at least every somebody who represents everything. Yeah. Yeah. Paul: is that swagger doc something that, you know, this orchestration layer would be responsible for? And then they bubble that down to the, to the individual sprint teams as they do the micro component. Okay. Gotcha. Natalia: yeah, yeah. No, it's, it's not, it's not only that, but it's, um, usually when you have too, ma too many people in a call, uh, yeah. The out the outcome is difficult to, Paul: Gotcha. Okay. Natalia: yeah. Paul: Representative member, it re this reminds me of this Google Calendar plugin that somebody, uh, founded a, at a previous Slack group I was working in, it was like everybody's Natalia: But the the point is that, or if you have Paul: And so it's like if you have 17 people getting paid, like $30 an hour, Natalia: a Paul: Wow. Natalia: committee, right. [00:18:00] That invites people over. Paul: Yeah, we've all been in all hands meetings. We know we know what those are like. Natalia: Um, Right now my job is a little bit different because I work in developer tools and, and there is a lot of that cuz I work for a very large organization. And Paul: So, so Natalia, do you find Natalia: have a governance layer and you can contribute to that with ideas. We, we are also very much a p i first. Paul: stack, be it, you know, the people and Natalia: But I don't, I, I don't work in Paul: In your Natalia: right now, or I Paul: it seems like you're, you're really invested Natalia: this job, Paul: pushing the boundary and, Natalia: But I try to, to, to participate of as many architecture, uh, conversations as possible. And I [00:19:00] have this website and then I also do public speaking, and I'm fully focused on, yeah, on trying to spread the word and the knowledge I got from, from. Work actually working on this for, for so many years. I, I hope I can, I can contribute to make a better web everywhere because I, I am also very much, uh, sorry. I'm also very much, uh, or very passionate about the web platform and, and performance and all these topics, so I, I really love talking about it. Yeah, Paul: You, Natalia: [00:20:00] so I put that out there because, uh, for a very long time I was working mostly as a front end developer. Um, I actually Paul: I mean, and you put content out actively as well. You, you know, not just coming on the podcast and talking, but you have things out there like, uh, could you talk to us a little bit about if, if Natalia: then I moved Paul: some of the stuff you put out your Natalia: frontend developer, and I noticed that a lot of frontend developers Paul: Like what is that? How Natalia: not have any. Knowledge of what was going on at an architecture level, or how those architecture decisions were made. Uh, they, they were questioning, why are we making things this way? And that was because ma, many folks, including myself, I come from a design background. Um, they don't have a, a computer sciences background, so they, they don't know a lot of those processes that. Before making those technical decisions and stack decisions [00:21:00] and, and so on. And I, this is one of the things I, I try to do, I try to educate folks that come from different, um, professional backgrounds onto how to do computer sciences more approximate in a more approximate way than. Um, academic speech, right? And the decision metrics is, is, is a process of putting many technologies together and, um, asking a certain question that may lead to making a decision to satisfy a functional or non-functional requirement. And then scoring each technology individually and then, uh, some in the total. Score and then saying, okay, I, I believe that for example, if I want to satisfy high availability, this technology or this service is [00:22:00] going to be more suitable because it has a higher score, uh, with respect to this other technology. And this is basically, um, what a decision metrics is for. So we can do this in the front end as well. We typically don't do it, but we can do it. I try to be as neutral as possible. Of course, I, I have a disclaimer somewhere that says that maybe my, uh, preferences transpire because it's inevitable. We're humans and we, we obviously have some, some likes and dislikes. Uh, but I try to Paul: And does what you offer on your site sort of Natalia: In the description of the technologies as possible. I just wanted, um, [00:23:00] to inform more of what, what all those terms that we are hearing over and over right now. Like, I don't know, server side rendering versus, um, static side generation versus. Whatever, uh, clients are rendering and, and hydration and partial hydration and resume ability and all those things that sometimes folks hear but don't quite understand. Uh, and then they can put it in those metricses and, and, and make decisions about how much they need or not a certain, uh, feature. Yeah. Yeah.[00:24:00] Paul: Beginner, beginner things that help, uh, beginners access that jargon is Natalia: And also because I don't Paul: I was starting to figure out on YouTube what the difference Natalia: I, Paul: server side Natalia: uh, again, I, I try to be just informative, Paul: and, all that. I was so confused. Um, it would be great to have, you know, a single point of. Natalia: of this in their Paul: Somebody talking about that. Uh, so people listening, you want to go check it out? You can go to microphone and dev, uh, to check out the website and specifically what we're talking about now, microphone and dev slash decision dash matrix. Natalia: Yeah, absolutely. Yeah, I do that. Yeah. I. No, I, [00:25:00] I always advocate for the user experience and, but in my case, the users are the developers, right? So, Paul: to have a really easy way to step into Natalia: we have to consider that there's always, like, in my case, I, I try to enhance developer experience or user Paul: like you, you have some sort of balance Natalia: top of services that are in Azure. So what I'm trying to do, Paul: with respect to user Natalia: Making sure that when developers are working with low services JavaScript developers, they have. Better entry point. They have all the documentation, they have all the tools. They Paul: Right. Okay. Yeah. Natalia: next. They know how to go about integrations, API specifications, all these things to end-to-end deliver an application. So what I do basically is I build all day with all these frameworks, with all these, uh, technologies. And when I find caps, [00:26:00] I try to find a solution. So that's my, my job more. Yeah. Yeah, yeah. Absolutely. Absolutely. Absolutely. And I, I feel a great advocate for developers because I've been a developer, so I can totally relate to any kind of pain that folks are feeling when they're trying Paul: a pretty good job because that you feel like Natalia: tight deadlines and I've been, I don't Paul: jobs. You feel like you're very useful Natalia: to deliver something and not finding Paul: you got, I mean, it must be empowering to help to empower people. That's like a really rewarding feedback cycle. So, Natalia: I want Paul: Very happy, very happy that you've, you've found like a really effective way to practice that. Um,[00:27:00] Natalia: I think the industry organically has been moving towards these smaller teams, working together and having multiple roles, uh, particularly Paul: you think is the Natalia: startup scene where Paul: that you're helping with right Natalia: different hat every day. And then, um, and Paul: I don't wanna call it a Natalia: think about Paul: inform teams Natalia: an application that a startup is building, Can be one Paul: or is this is something that has been in the industry that you're really just trying to Natalia: And this is why I was, I. Paul: and, you know, help expand Natalia: it depends on the context, what a micro part will be, right? So I think that many of the concepts that I try to express in this [00:28:00] website or in my talks, um, can be useful for this type of organization of people trying. Produce something that will be integrated later in a larger scope. Um, so it has a lot of applications, but I, I obviously didn't invent any of this. This was already out there. I am just trying to clarify certain aspects and learning myself how we can do this better. Right? Uh, I did a lot of experimentation, for example, with module. Right. Uh, when, when it was not even released. And so I feel very confident to try to steer things in one direction or another. Uh, but again, from experimentation, from, from actually building stuff and, and pointing out, this can be done better, right? Or this can be done differently or [00:29:00] this is great, which is also the case. What can be done better? I don't know. I think as an industry and, and as a community, mostly what we can do better is try not to hype each other so much on things that we are just exploring because that's, that's one of the, I. I think that the, the culprits of Paul: of the number one areas where you think Natalia: pains where we feel ourselves sometimes, right Um, that's one, one area where we could improve together as a community. I am really, really happy that we are moving away from the client side and back to the server rendering because I [00:30:00] think that the end users. Suffered quite some in the past. Uh, and it, it, it wasn't because we, we were trying to make them suffer, but because of how the technologies work, right? And how much Java script we, we were sending to the, to the client side and all that execution. I am from South America originally and I know that the speed rates and. And C P U capacity of computers in this side of the world where I was born are not always the same than we enjoy here in, in Europe or in the States. And that's something that sometimes as a developer community also we don't think about. Right? We, we develop for high end and for, um, optical fiber and for 5G and yeah. In the end, we need to think a lot more about the end user and the [00:31:00] business problems that we're solving. And when we do that, we offer better experiences. So yeah, that's, um, that's what I think that, that it's going to be getting better and better from now on. I think we learned the lesson. Paul: Because it's. Yeah, Natalia: Yeah. Paul: I. Yeah, I like that. We kind of got a two for one in your answer. We got a, uh, about hype trains and the general state of like how we're bringing things back [00:32:00] to the server, which is like a huge move and push that's coming in a variety of different frameworks right now. And if people listening want to. Uh, learn more about these different frameworks, Natalia: I think there is a lot of information about micro front ends, but, uh, online, um, including mine, but I always. Paul: a few of your frame favorite frameworks, Natalia: I invite people to experiment Paul: Uh, well, Natalia, before we Natalia: their own so they can have Paul: are, is there anything that you would Natalia: and particularly because of what we discussed before about hype and about trends. And it's not that anybody has bad intentions, but we get always very excited about what we're working on. So it's, uh, it's good to always have, um, some sense. Objectivity and test and try and think of the user first always. Yeah. [00:33:00] Yeah, I do. It's, um, it's in Spanish, so it's a little bit complicated, but it's maybe, I don't know. It can be spelled out. Yeah. And yeah, I, I love interacting with. On Twitter and other other channels. Yeah. Thank you so much. Paul: And right before we wrap up, one last thing I'll just say, if people wanna follow you on Twitter, do you have a Natalia: a great day. Paul: Yeah, we can spell it out. Yeah, per Awesome. Well, Natalia, thank you for your time and thanks for letting us pick your brain about micro front ends. And honestly, the state of how [00:34:00] they affect like web development as a whole was a really great conversation.