Micro-frontends with Natalia Venditto

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. 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 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 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 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 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. 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 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 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.

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 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 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 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 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. 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, 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.

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 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. 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 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

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 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 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, 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.

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, 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, 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,

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 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 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 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 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 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. 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 they affect like web development as a whole was a really great conversation.