{\rtf1\ansi\ansicpg1252\cocoartf2580
\cocoatextscaling0\cocoaplatform0{\fonttbl\f0\fmodern\fcharset0 Courier;}
{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
{\*\expandedcolortbl;;\cssrgb\c0\c0\c0;}
\margl1440\margr1440\vieww11520\viewh8400\viewkind0
\deftab720
\pard\pardeftab720\partightenfactor0

\f0\fs24 \cf2 \expnd0\expndtw0\kerning0
\outl0\strokewidth0 \strokec2 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.\
}