Steve (00:34.972)
Hello everybody, welcome to JavaScript Jabber. We are checklist today. I am Steve Edwards, the other bald host with the face for radio and the voice for being a mime, but I'm still your host. With me coming live from the purple room is Mr. AJ O'Neill. How you doing AJ?
AJ (01:00.013)
Yo Steve!
Steve (01:03.503)
Yo, whatever happened to yo yo?
AJ (01:07.938)
Take it away, Steve.
Steve (01:12.109)
All right, today in the tradition of a multinational podcast, we have Mr. Vitor Alan Carr. How are you doing, Vitor?
Vitor Alencar (01:23.04)
Hey, I'm doing good. How are you?
Steve (01:25.115)
Good. And where are you coming to us today from?
Vitor Alencar (01:28.68)
So yeah, I'm right now in Berlin, Germany.
Steve (01:32.135)
Berlin, okay. So we are here to discuss a topic called module federation and what it is and how it works and why it's important. I'm not sure how many of you are like me that when you hear the term federation, you instantly think Star Trek, but that is not what we're just, huh? No, Star Trek, you know, the Federation of Planets, United Federation of Planets. Are you getting your star?
AJ (01:50.862)
Did you mean Star Wars?
Vitor Alencar (01:53.368)
Thanks for watching!
AJ (01:53.806)
Did you mean Star Wars?
AJ (01:59.682)
I guess.
Steve (02:00.655)
Are you getting your stars mixed up AJ?
AJ (02:02.526)
I was thinking episode one in, you know, taxation without representation. Nevermind.
Steve (02:07.595)
Oh, right. Uh, no, that's the Imperial Senate and that's different. You need to go read up on your star history, I think.
Vitor Alencar (02:16.264)
Thank you.
AJ (02:17.659)
I do.
Steve (02:19.779)
Anyway, moving on to our topic. But before actually before we get to the topic, Vitor, why don't you tell us a little more about yourself, who you are, what you do, why you're famous, why people should give you money, etc.
Vitor Alencar (02:30.7)
Yeah. Of course, of course. So as you know, like my name is Vitor Alencar. I'm actually from Brazil. So I've been living here in like Berlin for quite a while now. I am a senior engineer and now like engineer manager in one of the startups here called Fin. I've been doing content creation for like the past three years. So this is why I got to meet like amazing people like them. Right. So.
I started to talk about JavaScript and like about JavaScript and scale as well. So lately I've been enjoying a lot of events and sharing a lot of talks like module federation. And yeah, this is where I'm here today.
Steve (03:13.139)
Excellent. OK, so let's dive right in. What is Module Federation?
Vitor Alencar (03:19.348)
Yeah, so basically, Motor Federation is a feature on Webpack that allows you to distribute your code in a decentralized way. So it's take leverage of micro front-ends. So pretty much, I think all the companies that I know that get to a certain point that they are super huge, and they really want to still introduce greenfield projects, they struggle with.
you know, like centralized front end. And I think.
AJ (03:52.482)
What does that mean? That's not a real term. Centralized front end.
Vitor Alencar (03:55.416)
Yeah.
Steve (03:57.039)
Yeah, I have to admit I haven't heard that term before either, at least in this context.
Vitor Alencar (04:01.844)
Yeah, yeah, just because same as the backend, right? Like I think at some point people start to decouple backend service from monolith to microservice and now they're trying to get back to monolith, but in a more flexible way, you have the same thing for the front end, right? Like you have a big, big front end. And how do you introduce new technologies? Just think about, you know, Air France, for example, like they have a huge system on how you book like tickets and how you, you know,
go from start to finish in the checkout process. And if they wanted to introduce a different framework now, that would be pretty hard, right? Like I think their system cannot stop or they're gonna lose a lot of money. So how do you break this down in a way that you don't stop, but you allow you to test new stuff and like to also divide teams so you can do stuff in parallel basically.
AJ (04:52.494)
Well, wouldn't you just, I mean, isn't that just called a web page? You just, you just have a different page and it loads different scripts.
Vitor Alencar (05:00.492)
No, not really, right? Just imagine that you have 150 developers working in the same system. At some point, they're going to run into trouble and bump into each other, right? So you have usually how the companies go. You have teams that they start in the beginning checking just the start of the flow, like how people come from Google, and they land on your page, so they have different metrics. And then you have teams that do the checkout part. They're very much interested in how customers just
pushing things to check out and finalizing the process. And usually, if you want to run a lot of A-B tasks, you have to be very careful, right? Because those features can collide to each other. So usually, what happens is that you have different teams doing different parts of the system. But they are still working the same system. So the idea is with module federation, you can create self. You can encapsulate those modules with all their business logic.
And then you can allow people to consume them remotely at runtime. This can give you more flexibility to divide in different teams that would be very specialized in different areas of the same system so they can have their own deployment, they're not going to like bump into each other. They can work in parallel and yeah, they can be more specialized.
Steve (06:23.091)
OK, so if I understand you, this is specific to one micro front ends that are using Webpack. Did I understand that correctly, or is this a bigger scope than that?
Vitor Alencar (06:34.676)
Yeah, now I think more bundlers are supporting this, but Webpack was the bundler that actually made the feature available in the beginning. It was very specific for Webpack. Now I think Rollup has adopted, and RSPack is also providing support for module federation. So now it's getting more and more spread out, basically.
AJ (06:59.106)
So on the backend, if I want to try a new framework or something, I just create a different service and then I have an API boundary and so the services are completely separate. And when one needs to speak to the other, it just calls the HTTP API and grabs it. Or in some cases of I'm feeling really lucky. I might talk to the database of the other service directly, but that's generally ends in sadness. So when I think about a front end,
Vitor Alencar (07:07.255)
Yeah.
Vitor Alencar (07:12.043)
Mm-hmm.
Vitor Alencar (07:26.418)
Yeah.
AJ (07:28.266)
And having different applications. I think the same thing you, you do a redirect, you have URL parameters. So, you know, redirects, it has some parameters so they can load the state and the other app can redirect back. You know, and that's how OAuth works and lots of other things where, I mean, OAuth is essentially microservice on the front end. So is this like, how does this compare to that kind of model? Cause I don't.
Vitor Alencar (07:34.264)
Mm-hmm.
Vitor Alencar (07:55.714)
Yes.
AJ (07:56.49)
I don't have a brain space for this yet.
Vitor Alencar (07:58.836)
Yeah, so just imagine that you have, let's say, an e-commerce website. And you notice because, let's say, you start with Angular 1. And now you really wanted to push to try a specific team to use React. This would be very messy. Either you're going to have to completely isolate one part of your system, have a full redirect, and then have a different module being like another URL loading.
With module federation, the idea is you can create what they call a host. A host will load modules. Right? And you can...
AJ (08:37.418)
Is that a what is a is that a web page? What is that? What does that look like?
Vitor Alencar (08:42.152)
Yeah, so basically, there is these two basic concepts in module federation. One is the host. One is the remote. So imagine a page that this page is going to be the entry point of all your JavaScript. Yes, exactly. This page will load Webpack and will just orchestrate what's going to happen afterwards. This is what we call the host. I'm going to host modules. And those modules can be fetched at runtime.
AJ (08:56.754)
index.html.
Vitor Alencar (09:11.288)
So you can have your index page. And now what you can do, basically, you can have different remotes. Those remotes, there are pieces of logic, self-encapsulated, that can be even different frameworks. So you could have your button, like the checkout button, being served from a different host, or a different remote, sorry, that's React. And your whole application can still be Angular, but you're trying this specific module that's in a different.
remote. So now you can have those pieces being orchestrated at runtime. And you can define which pieces of your software are different remotes. So you can divide them. You can divide teams to work specifically with parts of the system. And they all live inside the same host.
So it's like Lego pieces, right? Now you can encapsulate it in little containers that they know how to run. They have their own business logic and they can be fetched at runtime.
AJ (10:11.47)
So I'm guessing then the host has to contain the router and has to communicate the params between these.
components slash apps.
Vitor Alencar (10:27.06)
Yeah, the host is responsible for injecting the remote to the page, right? Like telling how you're going to run, basically. So the host has to decide how to resolve all the dependencies and how to basically orchestrate how things will run. So when you are defining a remote, for example, you define a set of properties that say, OK, I need React version X. I need those dependencies. Let's say I use tailwind or whatever.
When the host is getting this remote, it's going to try to resolve those dependencies. But this is happening at runtime. So it's like, it's promise-based and you can literally consume those things over the wire.
Vitor Alencar (11:12.436)
Yeah, and I think it's pretty good, especially for, like I mentioned, like big systems, right? Like you have to scale your product, you have to keep innovating. And especially with legacy systems, it's very hard to move things forward because you have a lot of logic, you have a lot of structure that was built over time and to have this flexibility of to say, okay, I'm gonna get the banner, V1 banner from...
this remote here, specific remote that's hosted as an S3 file, for example, at AWS, and say, yeah, I'm going to have a different checkout that's being hosted from another S3 file, and be able to change those configurations on the fly. It's very nice. It gives a lot of different possibilities.
AJ (12:03.896)
Now.
It seems that the trend has been more vertical integration. So if I'm using, I'm not really a front end person. I do, I do JavaScript libraries for the front end and I do. Node and go on the backend, but
AJ (12:33.122)
Things are becoming more vertically integrated. You have stuff like V and I don't know what all the other ones are, but typically your build process is streamlined the whole way through. So it sounds like this would require a different build process.
Vitor Alencar (12:55.888)
Yeah, I mean you can still have for example, let's say a mono repo right with all your different micro front ends and the only like requirement especially in the beginning was that you have to install this plugin from Webpack the module federation and then you tell like your configuration files like the host and remote configuration files in the webpack config and This will tell how you bundle the application. So it gets
decentralized because you're literally building static JavaScript or sharing how to consume JavaScript over the wire. So you can have still like a monorepo setup that has all your. Like dependencies and how you interact with them. It's just that how you deploy those applications. It looks very much like you're going to host a static website, for example, and just push to like S3 bucket, for example, and then you can have versions of it.
you can still version it and it's still going to work. It's just that now you can have those micro projects very specialized that specific teams can work.
AJ (14:05.474)
Well, what I mean is like people, people use something where there's an init command and it boilerplates out their project and then they use a build command and a dev command and it's kind of for it, it's for the whole, you know, the whole project. So does this with web pack, is there something like that where you can
Vitor Alencar (14:18.452)
Yeah.
AJ (14:35.034)
In it. Well, I mean, it sounds, it sounds like what you're saying is that this is for when you already have a project that's been established and you want to add something else into it. But how does that, how does that work with things? Like what Steve, you're going to have to help me out. What are the, what are the current build systems on the front end right now?
Steve (14:55.951)
Well, exit VEAT is, is the one that seems to pretty much taken the world by storm. And it uses, well, VEAT does the hot module reloading and all that, but then it uses roll up under the hood to actually do the bundling for deployment. And production you got web pack. And there was another one was it turbo. I don't know if it's 37 signals, turbo. There's another one that, you know, had a whole thing about, but there's, there's a few.
Vitor Alencar (15:10.968)
Yeah, I mean.
AJ (15:19.054)
There's a Turbo Pack. OK. And then next. Is next in that same category? Or is it?
Vitor Alencar (15:23.618)
Yeah.
Vitor Alencar (15:31.607)
No, like turbo would be the bundler for next JS.
Steve (15:34.557)
Yeah, next is a React tool. And I don't know much about it not being a React person, but yeah, but no, Nextin, that's a different area.
AJ (15:35.369)
Okay.
Vitor Alencar (15:38.097)
Yeah.
Vitor Alencar (15:44.128)
But the module federation plugins available in a very large number of bundlers. So you can use with Webpack, but you're not restrict to it. RS-Pack supports it. Vite supports this as well. So you can use with Vite. You can use with Rollup, ESBuild. So all those tools, all of them, they support this scenario. So you can have actually what you say that you're going to enter the project, run your dev command.
AJ (16:03.917)
Okay.
Vitor Alencar (16:12.128)
And you can even specify, I want to run just this micro frontend. I want to run the whole application. So spin up all the micro frontends, or all the remotes with this host. And you can have this running with just one simple command. And also for the build, you can just go and say, build my application. And I'm going to just orchestrate the deployment or the build process for all of those micro frontends within this project. So you're not restricted in terms of setup.
The whole idea is to give you more flexibility. So the bundle is almost like, it's actually almost the opposite. So now you have those small JavaScript files that tells you like, okay, I'm self-contained. I contain all my dependencies here. So let's give you a more concrete example, right? So let's say that you have a specific place in your system that you use a date format library, but you only use in the specific.
place. So this can be a part of the micro frontend. And you're only going to run, you're only going to consume this dependency once you go to the specific place where this dependency is loaded. So in runtime, you'll not only get the whole module, but you get the dependencies that come with it. So you're like literally saying, okay, my application doesn't depend on this library to boot.
Basically, I can access it and every other page that doesn't use it, I'm not going to load it. But when I get to this specific point, I'm going to load this micro frontend, this remote, and I'm going to load all those dependencies as well. And yeah, that's all over the wire. So you can easily see the network request being made and all the JavaScript coming over the wire and how Webpack, for example, will load and run it.
Steve (18:10.055)
So here's a question I think of when I think of modules is, does, you know, there's always the conversion from the old common JS required to ES6. Where does that play into this whole structure? Does it?
Vitor Alencar (18:23.736)
Thank you.
Vitor Alencar (18:27.292)
I don't think so, because it's more like how the bundler, like in this case, how the plugin will read your module. So it is already push with some webpack meta tags. So it really understands what type of remote you're getting from. So if it's just, for example, it's just a piece of JavaScript that you want to share, it's just going to run it.
If you have any dependency, it's going to try to look for the module resolution, which is like, you're going to try to see where this dependence is coming from, and then enable this for the user. So it doesn't really collide with the modules that you see in OJS. It's not about that. It's more like how you consume those little bits of JavaScript through the plugin. So that's...
The Modular Federation plugin knows how to do the modular resolution for you.
Steve (19:28.455)
So if you want to use module federation, then this is a webpack plug-in or a beat plug-in that you drop in. Now, assuming in the plug-in, you're going to have some configuration about routes for where your remotes are or your hosts are.
Vitor Alencar (19:37.311)
Yeah.
Vitor Alencar (19:45.225)
Yeah. Yes. Yes, you create basically the declaration of a host and a remote. So you say that you have an application that's host. I'm going to consume different remotes. And for every remote, you have also a declaration that say, I'm a remote. I'm going to be hosted at this specific place. Those are my dependencies. This is where I need to run. And when you load a remote into a host,
the host tries to resolve those dependencies and to load the specific piece of code. So it's pretty cool when you want to have, for example, different frameworks running on the same page, or let's say that you, I don't know how familiar you are with, for example, Redux. I think Redux was super popular like not long ago. And the idea that you have a centralized store. So what you can actually have, let's say that you have, the way that you communicate with your front end is for messaging.
So you send a message, say, hey, I have the state. This is the state transformation. And you have a remote that's just responsible for the store. So now you have a remote that knows all the data. And then you can make this remote to talk with different frameworks. So I even have an example, for example, in one of the talks that I share, a web application that I built. There was an e-commerce where every step
was a different framework, just to show that we can have Vite, we can have Svelte, we can have React, and we can have pure JavaScript talking with the same store and all responding in real time. So there was no reloading of the page, nothing. It was like they're all talking to a data layer, and this data layer is updating the data, and I'm consuming those remotes in runtime. So if I want to say, OK, now I'm just going to have React on this website.
then I would change the remotes to only point to the React ones. If I want to say, now I want to have this mismatch of React and Vite, I can also do that. So adopting new frameworks could be easier because of this architecture. And of course, there's some pros and cons, right? There is some advanced strategies. But this is pretty cool because I think very big companies now, they are really using it. And that's become more and more common to see. So for example, the TikTok web page.
Vitor Alencar (22:08.78)
use module federation to load different modules. And other big like e-commerce like Lulemon, they also use very heavily module federation. And for them, it's pretty nice because it really means that the way that they do A-B testing, it can be very much efficient. Like you can have different teams build different product grids. And if one fails, let's say there is a bug in one with just changing a feature flag or something they can do remotely on their site.
they can share a totally different configuration. So the next time that you reload the page, you have a different sets of remotes and you consume different versions of those like encapsulated logic bits.
Steve (22:54.727)
So it seems like this is a lot of work on the remote end, because you basically have to define all your different remotes and your URLs and where the code is. So is the code just sitting? I mean, for instance, could you pull it from NPM? Are these GitHub repos that code sitting in? Is this compiled code sitting where that you're pulling in? How does that whole process work when you're, in terms of defining your remotes?
Vitor Alencar (23:22.568)
Yeah, so you have two different strategies. We have basically configuration that you define at build time. So you can define before building your application or your sets of remotes and all your entry points, basically. You can say, OK, I have a host, and I have three different remotes. All my analytics, they're a different remote. All my UI comes from a different remote. And that's cool.
But they also have some advanced strategies, what we call dynamic remotes, where you basically create a function that can get a specific remote at runtime as well. So you can tell your system to say, OK, right now, depending on a feature flag, please fetch this different remote. So basically, everything that you can predict that you're going to need at build time, you can just specify in this webpack config.
in the host and remote. But you also can consume them as a variable in your system that you say, hey, by the way, now try to fetch this remote that are going to pass as a URL as a variable and try to load it. And then you can have some try catch to prevent something to happen if you cannot reach the network layer or if you have to take into account any kind of missing package, basically. And there is.
tools nowadays that they really help you to orchestrate this, because the same as Docker containers, right? If you go to the back end, that would be the most close analogy, I think, that you have your system, you have to scale and you orchestrate how many machines you have, you know, you have auto scaling, so you can have pretty much the same idea in the front end. And you have, for example, dashboards like Medusa that really tells you, it's quite a crazy, like you see there, okay, I have this product here.
my e-commerce and those are the micro frontends that I'm requesting at runtime and those are the versions and you click a button and they can change the version and then your application will just react to it and you don't have to redeploy it basically. So you can do this whole orchestration also at your site and your dashboard and try to connect those modules together.
Steve (25:50.695)
So what is the, it sounds like the idea of this is being able to handle multiple front ends, right? Multiple, whether it's different frameworks or whatever your use case may be. What do you think, and is there a hard line? What is like minimum scale where you would want to start using something like this? Like two separate frameworks, five, you know, what?
Vitor Alencar (26:16.908)
That's a very good question. I think when I give talks about model federation and micro frontends, people get all excited, like with all JavaScript frameworks, they wanted to try it right away. But I usually, what I recommend is, it's about scaling of teams, I think, at first. So I would not try to do this at small products because there isn't, I think the benefits are not there for like small...
then like applications, I think when you go to medium to larger size, and especially of team size, then it starts to make sense, right? Because I think the flexibility that you get here is that you can have specialized teams, you can have the checkout team that, for example, works only with checkout. It doesn't have to know all the design system, it doesn't have to know all the analytics, it doesn't have to know all those parts of the system that
is important for the system as a whole. But if you have a focus team, like three people working just this specific path, they can take advantage of the speed of building stuff and just connecting to the main application, not having to do a full pipeline deployment to build the whole thing just to make sure that they change a button. So the idea here is if you have a medium to large team in a big company or a big project,
break it down into smaller micro frontends. And those micro frontends can talk with each other. So I think that's kind of a downside for small applications, because you add a lot of overhead. You have to orchestrate them. You have to make sure that you create some boundaries for specific errors that cannot bubble up. And for small teams, I think this is a downside. But for bigger teams, you're having those problems already. And for bigger companies, like,
Lulemon, Best Buy, and Epic Games, they all use modern federation. And this is why they really need this flexibility of pushing things over the wire, be able to react to client feedback or be able to test things and do very heavily A-B test. And for those specific cases, I think the pros are much better.
Steve (28:39.183)
Hmm. Okay. You're muted AJ.
AJ (28:45.854)
that are using this in production? do you know of large companies like that are using this in production?
Vitor Alencar (28:52.424)
I think Lilliemo is the one that I already mentioned, right? Like they have huge Euroskeys. They are like super huge e-commerce. And they use Model Federation. Like if you open their page right now and you look for like remote entry on the Network tab, you're going to see all the JavaScript that comes to it like as remotes. So they are quite big. And then they really use Model Federation at production.
AJ (29:18.646)
Wait, sorry, what was the name of them?
Vitor Alencar (29:20.808)
Lulimol?
AJ (29:23.666)
Lulim- Lul- Luliman?
Vitor Alencar (29:25.02)
Oh, yes. Yeah, sorry. Yeah, yeah, Lulamun.
AJ (29:28.667)
Okay, I'm not familiar with that.
Vitor Alencar (29:32.136)
Okay. Yeah. They are like a big company. Um, yeah. E-commerce. Um, last time that I checked Adidas has also use it, uh, Shopify partners and yeah, you have also, I think Best Buy I checked and they also use like, um, Model Federation and TikTok web uses as well.
Steve (29:35.651)
Oh, lululemon? Yeah, like apparel, clothes, yeah.
AJ (29:42.834)
Oh, okay, okay.
AJ (29:59.493)
Ha ha ha. Tick tock boy.
Steve (30:03.59)
No, no, no.
Vitor Alencar (30:05.873)
Yeah, it's quite interesting to see, right? Because if you think about TikTok and how many people are there every day to be able to create something that really scales and stays up no matter what, that shows that, yeah, I mean, there's definitely some pros to be seen there. It also has a lot of challenges, right?
When you try to orchestrate those things and in production, it's not easy and you still need some extra tools to make sure that you can have over-survability. And this is the area that I think that I see that's start to grow now where people identify that module for their school and now they are starting to build more tools around it and make the process a bit more seamless.
Steve (30:58.215)
So what are, so it's talked about scale and when you would want to use this. Are there any anti-patterns or contraindications or whatever term you wanna use for when you shouldn't be using this, even if you have appropriate size?
Vitor Alencar (31:19.08)
Yeah, I think it also depends on how tightly connected is your system, right? If you, I think first step before module federation, you should be able to break it down and to separate the areas. So what I see a lot of people failing is that they have a business that it can be very much like one just unit. It's like, it might be complex or not, but it's still one unit. So there is no point of breaking this down into different teams or different...
adopting micro frontends, right? Because modular federation is just a layer of communication for micro frontends. That's the only thing that it does. So for those ones, I consider like a bad practice to just jump right away. And what I like to do is actually do the incremental adoption. So a lot of people also just jump the gun and trying to convert everything to, okay, I'm gonna have 10 like little remotes that just do one thing.
But in fact, if you just take first the core parts of your business and things that everyone uses, right? For example, analytics, it's something that every system that I build, at some point you have to put some tracking there, it's a very good candidate for micro front-end. And if you start in those boundaries, you have much more chance to succeed because there is, I think there's a lot of information there as well on how to create like specifically
micro-frontends on this, like specific for this area of like analytics. And then you can start to encapsulate the logic. And then I think later stage, you can do UI, you can do all the parts of your, your system as well. But I would start very slow, like separating the most important parts of the system and then migrating things a little bit to the host and remote areas.
Steve (33:16.711)
So out of curiosity, I know you mentioned showing one of your apps in your talk, and we got a video linked to that in the show notes. Do you have any like any Git repos or anything that shows this in use, being the visual person that I am, my head is sort of swimming right now, just trying to imagine what code looks like. And so do you have any like actual solid code examples that you can just basic stuff you can look and play with?
Vitor Alencar (33:43.085)
Yeah, I can provide as well. I have one repo of a workshop that I did that I did a very small e-commerce where like we have different, uh, micro front ends for like the checkout for the product list. And was even interesting that you have replication layers because what you can do is you can also mismatch hosts and remotes. So you can have what they call like.
bidirectional sharing, where I'm a host, but at the same time, I expose part of my system as a remote. So in this specific example, you can see that I have three endpoints and three files that all of them, they show the same store, but they are different microfontans. So I think I can share and show the link to the GitHub repo. I just have to open it.
Steve (34:35.104)
Okay. All right.
So we've talked about, I'm just looking through the notes we have here. Do we talk about self-healing?
AJ (34:47.744)
Oh yeah, what's that about?
Vitor Alencar (34:51.undefined)
This is one of the advanced, I would say, strategies that we can do. It's pretty fun. I also show you one of my talks. I can also share here a link to the GitHub that's really interesting is the concept of, for example, in React, the way that we catch errors is through error boundaries, right? So we have those boundaries that we basically catch exceptions. And the idea here is like, let's say that you have a new version of a button.
But I think it's very easy to visualize. And you want to push this to your current micro frontend. And you want to have this distributed to production right away. The idea is that you can build a system within your host that if any exception gets caught, you can also tell how to revert to a previous version. So the.
the dynamic loading of a new remote can help you to switch those remotes on the fly. Basically, what it does is, let's say there is an exception being thrown in your application. You can tell to, OK, can you try to get version one? And in runtime, we just swap this component and it show you the previous version that was working. So you can have, like this.
capability of self-inhaling the whole application, because now you version areas of your code. And this can be swapped over the wire as well. On the fly, you can say, well, this little checkout module that I built doesn't work. Try to get the previous version that was working. And yeah, the user would just perceive something loading in the screen, and then it's going to get the previous version right away.
Vitor Alencar (36:44.988)
And another thing that's there as well, it's about trying to solve dependencies. So since we have this shared decentralized architecture, let's say that I have a dependency list in one of my micro frontends that's not present on the host, but another micro frontend has it. And what the Webpack module will try to do is just try to solve.
this dependency on the fly. So it's going to start to go down to the tree, asking who has this version of React, for example. And if one of the remotes have it, they would just load for the specific remote. So now even the dependency tree can be also decentralized. So the main host can heal itself and try to find the correct dependency.
Steve (37:38.631)
So it sounds like self-healing is basically just fall back. So if you don't have something, fall back to a previous version or fall back to this other repo or something like that, right?
Vitor Alencar (37:47.924)
Yeah. Yeah, the difference is that it happens with the user in the page. You don't have a reload. It's literally like you see you click the button. My example that I show to people in my talk is you have this specific button that if you click three times, they're going to throw an exception. And what it does is literally swap the button to the previous one after the exception being thrown. So you're still going to be able to capture the.
there or in your sentry file or whatever system you use for like to track errors. But for the user it's like, oh, the button just changed. And if I click again, like the whole system still runs and still like keep running and it doesn't disturb you basically.
Steve (38:38.887)
So let me make sure I'm still getting trying to get my head around this a little bit from a build time. You're talking about all these fallbacks where the self-healing term where, OK, this isn't here. So now let's fall back and use this. So how does that work from a bundling and production standpoint? So in other words, I'm going to have a fallback to something else. But I've pre-bundled everything. It's downloaded to the browser.
So is it A, a dynamic where it's going out and re-importing that JavaScript now, and there you run into the whole issue of all the JavaScript downloading we're trying to do less of to make things faster for slower connections and older phones? Or do you just load the snot out of everything and then it just, you know, ahead of time with huge bundles and then it's just flipping back and forth in the pre-built JavaScript?
Vitor Alencar (39:28.976)
It's dynamic, right? It happens over the network. So the host knows what it needs to receive other remotes only. So this is the only JavaScript that gets initialized. And as you load those remotes, then you're loading the code that gets basically bundled into it. So this button that I mentioned, it's a micro frontend. So my host doesn't have this button and imports as a JavaScript module.
It's a normal JavaScript module that's like the same way that you do any kind of import. What it does, and as soon as you enter the page, the module federation plugin will try to solve this module. So it's going to make a request for a certain endpoint. Then you're going to get this JavaScript back over the wire. And this promise will resolve. And then you're going to have the module being injected into your page. So
This fallback system, it's at the runtime. So when user is using the application, basically what happens, another module gets loaded. So you basically make a request to this specific endpoint, and then you get more JavaScript. And then once it's cached, it's in your page. So even if you do the same request again, if it's cached, you're gonna get the version that you had before.
Steve (40:47.111)
So it sounds like you need to make your remotes pretty lean and mean.
Vitor Alencar (40:50.736)
Yeah, that's one of the downsides, right? Like it's actually what you mentioned that, I mean, it doesn't come for free. Now you have this dependency of like your code now needs to be orchestrated. You need to tell which parts of a system can be there like build time. So everything that you need from the start and whatever else you're going to have being loaded over the network. And yeah.
AJ (41:16.814)
So that that's not going to be included in a web pack plugin where it is there a meta framework for all of that you're talking about.
Vitor Alencar (41:28.792)
So the module federation plugin would put into your first build the information on how to solve the module resolution, basically. So when you run the host application, the host application would have the piece of code that knows how to resolve modules.
AJ (41:50.878)
Okay, but where I'm confused is what is the brand name of the thing that you're talking about?
Vitor Alencar (41:58.816)
So yeah, module federation is like the technology. Like it starts as this Webpack plugin, and this is what you use to do the module resolution. It's a Webpack plugin that can be used.
AJ (42:12.418)
Well, I get I get that. But when you're talking about the orchestration layer, like what's the what's the brand name of the orchestration layer that you're talking about?
Vitor Alencar (42:24.648)
Yeah, that's the whole module federation. I don't know if they have a different name to do that. Maybe there is more technology that I'm not aware of it. I'm not...
AJ (42:28.29)
Hmm.
AJ (42:35.574)
Well, I mean, okay, so maybe I misunderstood. What do you mean by orchestration?
Vitor Alencar (42:43.116)
So the idea is you install this plugin in your current project. When you build it, now it will have in your bundle, first bundle, the information on how to be a host. A host knows how to load remotes. So the information of, OK, if I make a request to this bundle here, to the specific JavaScript, I will know how to do the resolution of it.
AJ (42:58.423)
Mm-hmm.
Vitor Alencar (43:12.768)
I would know how to load and to request more dependencies or how to just inject into the page. And the remotes are built to also like to output this specific, what they call entry point. And it's the specific file that contains the JavaScript that will be included in the page, in the case the remote, once you request it.
Steve (43:39.547)
Sounds like almost like a Lambda function.
Vitor Alencar (43:43.572)
Yeah.
AJ (43:44.418)
Yeah, that's, that's the kind of thing I'm trying to figure out is like, is it tied to a specific infrastructure? Um, is it, is it just your hosting static files? I'm not. I, conceptually, I think I get what you're saying, but the, the specific, where does this
Vitor Alencar (43:59.82)
Mm-hmm.
AJ (44:06.338)
physically live or how do I how do how do I click the button to have it you roll back or something like that?
Vitor Alencar (44:10.36)
How do you post it?
Vitor Alencar (44:16.833)
Yes. Yeah. So this you can create in your system, right? This is also the example that I gave in React. I created a little hook that was just responsible to do the request for me. So basically, the whole system was, okay, if you see exception being for all, do a request to this endpoint here. And now...
talk to with the module resolution to inject the specific module in my page and replace this one. So this is what was doing at runtime. So the differences with frameworks, again, like React Vite, the idea is that you build once, right? Like you build and whatever you push live stays live. You cannot get code from like different remotes, right? But in this architecture,
of like micro frontends, you can use module federation to communicate how you're going to load different modules or different micro frontends.
Steve (45:25.707)
Okay, so I guess I think we've unless there's any other topics about this. We haven't covered what's guess as you put it in the notes, what's the takeaway?
Vitor Alencar (45:39.336)
Yeah, so I think this is quite exciting, right? Because it's a different approach to what we have seen becoming more and more popular, where we are adding those frameworks, for example, like NASJS, where we are building very complex systems and doing server-side rendering as well and a lot of things. But I think for very huge and large complex applications.
the flexibility of being able to push code over the wire and really have those Lego pieces that connect to each other. This is pretty much needed, right? So I think this is a very interesting, different type of architecture that I believe that's going to evolve more and more and more and become more and more popular, as same as microservice, the idea of microservice, they start to evolve.
and people understood where to adopt microservices, where like monoliths make more sense, I think you're gonna have something similar to frontend and how we build frontend.
Steve (46:52.375)
OK, well, I know my head is spinning. AJ, I don't know about yours, but this is definitely for larger code bases, larger teams, larger companies. And a lot of us may or may not ever see that complexity, but it's certainly out there. So I did find the Webpack module federation plug-in and.
We will have a link to Vitor's talk on module federation. I think he's mentioned you give a couple of code examples. And examples was hosted by Prisma, I believe. So we'll put that in there for sure. And with that, we'll wrap up our talk of module federation and give my head a rest. And so we'll move on to PICS. PICS is part of the show where we get to talk about whatever we want to talk about. It doesn't necessarily have to be tech related.
AJ, you got anything for us?
AJ (47:54.146)
Let's see. I'm excited for the possibility of, well, the reality of the Nintendo switch too, but there's not, there's not any, I guess I'll pick the channel where I've been listening to the little tidbits of leaked information here and there as it arises. So there's a channel called spawn wave. The guy talks about all sorts of video game stuff, Xbox, PlayStation, whatever.
Vitor Alencar (48:06.016)
Thanks.
AJ (48:22.422)
But he's kind enough to put in his description time codes to everything. So whenever he posts a video with Nintendo in the title or description, I just click in the description and go to the part where he talks about Nintendo. And it's been interesting to hear the rumors about the switch to and I'm really hoping that it is, in fact, backwards compatible. Other than that, I am still going to pick the things that I picked last time, because I just
have been getting so much valuable information about relationships and the difference between men and women and in the kind of about a month now that I've been researching
Vitor Alencar (48:55.219)
Okay.
AJ (49:10.146)
this kind of stuff more. The quality of my marriage has improved. So Suzanne Venker with the Suzanne Venker show and her podcast, the slogan is something like be counter cultural. And she speaks hard truths to women but in
listening to her, you can, you know, you can reverse engineer the, you know, the w with both, both of these people that I'm picking the other one is Alison Armstrong and her book, the Queen's code. You know, it's, it's very, uh, interesting to, to hear them speak to women, but then, you know, about men and be like, Oh, okay, this is the difference. This is where we're miscommunicating. This is why I'm like,
Why aren't you getting this or like, why are you looking at me? Like I'm stupid, you know, just a lot of that, a lot of that stuff. And then, um, you know, of course they talk about intimacy as well and have some great tips there. So that's, uh, I'm gonna, I'm gonna pick that cause that's what's the, those two, those two podcasts. Well, Suzanne banker has a podcast and then Alice Armstrong, she has a couple of. Of, uh,
videos online, but the book, the Queen's code is like her, her condensed version of everything she's learned and that however many decades she's been doing relationship coaching. So I'll go with that. I don't think I have any technical picks for today.
Vitor Alencar (50:32.6)
Thank you.
Vitor Alencar (50:42.152)
Okay.
Steve (50:52.099)
Alrighty. I will go next, uh, before I get to the high point of every episode, my dad jokes, I got a couple other legit things to pick, um, interesting article today, uh, regarding transplants, uh, it's an AP article and it's, I don't know how well known it is, but there's really a shortage of organs available for trans people that need transplants where the kidneys, heart, liver, et cetera. And so.
Vitor Alencar (51:10.277)
Thank you.
Steve (51:21.847)
In one case here, it happened in, um, I think it's Washington DC. I'm not sure. Oh, it was Maryland. Uh, guy got a pig heart transplanted into himself and supposedly it's all going well initially. I know that, uh, from my very slim understanding of medical technology that I learned from watching ER on TV. Uh, I know that they'll use pigs feet to practice sutures and pigs have enough.
Vitor Alencar (51:27.897)
So, cheers.
Steve (51:51.471)
morphological similarities with humans that that's why they try things like this. So it'd be interesting to see how long this heart lasts in this guy, but, uh, if it does work, then that's certainly great for those that are, uh, literally dying in need of a transplant, uh, that are unavailable. Uh, second is a couple articles that I saw on pass keys. Uh, I haven't really delved into this too much and it's basically a way of
Vitor Alencar (52:00.061)
Let's see.
Vitor Alencar (52:20.629)
Thank you.
Steve (52:22.091)
Allowing you to sign into something without passwords because I mean I don't understand that because I know passwords never get hacked and they're always very reliable But they want to get rid of passwords I'm kidding people and so There's a post github has them generally available now They can use pass keys and then there's a corresponding article about what our pass keys And in both of these on hacker news today written on a place called Tom's
AJ (52:30.516)
Yes.
Vitor Alencar (52:39.956)
Thank you.
Steve (52:50.611)
Tom's Guide talks about what are pass keys, and everything you need to know about the death of passwords is the title. So I haven't delved into these too much. The best I can understand this from skimming through the article real quick is that basically, instead of storing on somebody's server where these keys would be available, if there's some sort of data breach or hack, you store them locally. And so anyway, that's all I know right now.
Vitor Alencar (52:56.832)
This is the right one.
Steve (53:18.619)
We'll put the links in the show notes so that you can read them. And then we get to the dad jokes of the week. So recently, I went to a Gambler's anonymous meeting. And the leaders, I didn't have a lot of faith because the leader started off by saying, I bet you're all happy to be here.
Steve (53:41.935)
Get it? I bet. Anyway.
AJ (53:43.874)
Yeah, it.
Steve (53:48.384)
All right. So my dad gets to the ground. So the other day my son came in and told me, he said, dad, I watched the guy do 100 straight pushups. Can you do the same thing? And I said, sure son, I could probably watch somebody do 500 straight pushups.
AJ (53:49.142)
That one gets a groan.
Vitor Alencar (53:57.586)
Thank you.
Steve (54:09.331)
I think he just needs to be more specific in his questions. Right? And then finally, the other night, my wife and I were out somewhere and we got a flat tire on our way home. We were driving home and she asked me if I could change a tire. I said, why? What I'm wearing is just fine.
AJ (54:09.902)
Sounds good.
Vitor Alencar (54:18.406)
Thanks.
Steve (54:32.059)
So those are the dad jokes of the week. Vitor, thank you. Thank you very much. Vitor, what do you have for us for picks?
Vitor Alencar (54:32.644)
So.
AJ (54:35.319)
Thank you.
Vitor Alencar (54:42.456)
I have actually two books. I think the first one, I don't know if you are much into music, but I am very much into music production as well. So there is this famous producer called Rick Rubin. Very legendary. Yes, yes. I absolutely love him and I really like the way that he handles music production. It's very much different from every other producer. He talks a lot about...
Steve (54:56.816)
Yes, I've heard the name.
Vitor Alencar (55:08.928)
meditation and removing complexity from music. So he has a book called The Creative Act, A Way of Being, and it's pretty, pretty cool. I already bought it. I'm dying to receive it here at home, like waiting for it. It's super cool. And the second one is actually a free book. If you want to have online, that's also super nice. It's for Eddie's money. He works at Google and that's also talks a lot about like,
philosophy and the ways of seeing life. I like those things a lot. So the book is called The Stoic Mind. So it talks, yeah, the stoic mind. So it's talked a lot about stoicism and philosophy. Yes. And I think the online version is free. And if you want to have the hardcover, I think you pay for it, but it's also very, very nice book.
Steve (55:49.756)
stoic. Gotcha. Okay.
Steve (56:05.223)
You know, talking about music, I'll, uh, I, I used to play, so when I was growing up, I played, uh, trumpet going up through high school, had a lot of fun, but never really, uh, continued after college, just cause the time, I mean, was something like that, just, well, any music, you know, it just takes time to practice and get into it. And so I sort of let that go by the way, but then I picked up guitar.
Vitor Alencar (56:06.078)
Yes.
Steve (56:30.863)
little bit. I was in college, not enough to really, I didn't really study. It was, you know, I can play chords and because I had the musical background. So recently I started taking piano lessons again and I'm 54. I'm taking piano lessons for the first time. So that tells you, uh, don't let age stop you. Um, and I had actually started taking them a few years ago from this guy, won a prize at a fundraiser for a couple of free lessons with this guy. And he does all the accompaniment for my kids, uh, high school. And he's a really good player, really fun. And so I started playing.
Vitor Alencar (56:39.672)
So nice.
Vitor Alencar (56:45.979)
Yeah.
Steve (57:01.047)
uh, some lessons again, this time I'm going to sit down and I'm going to learn it right, you know, learning, uh, chord progressions and, and the keys and all that stuff instead of just, you know, conversational type approach and, uh, some of the music I've always enjoyed listening to and, and I've tried playing a little bit in the past, I've taken lessons is sort of the new age stuff like, uh, George Winston and, uh, Suzanne Siani are a couple.
Vitor Alencar (57:18.183)
No.
Steve (57:29.767)
favorites that I've had. And he gave me a song to play and it's gonna take me a while to get to play it. But I loved it as soon as I heard it. And it's an Italian guy named Ludo Vicio I naughty. Never heard of the guy. But he's so good. Oh my gosh, some of his music is just it's really you sort of have to like it. You know, if you're hard rock or you might not like it. It's just great stuff to sit and listen to when I'm working. Oh, so you know,
Vitor Alencar (57:46.014)
Yeah.
Vitor Alencar (57:50.689)
it's
Vitor Alencar (57:54.22)
He's great. I mean, there's a playlist on Spotify called like Peaceful Piano. And he is like the first one there. Like there's a lot of like tracks from him. Super cool.
Steve (57:59.342)
Uh-huh.
Steve (58:04.239)
Yeah, I got this one. Yeah, he has it. He has an album from just recently called Moments of Peace. Um, the piece I'm playing is a little older. It's called I journo. Uh, really, really fun song to, to play. I'm sure my family's tired of hearing me play it now, but I, I certainly love practicing it. So anyway, point is, uh, I naughty is a great E I N A U D I is his last name. Great guy to listen to, but, uh, like I said, even don't let yourself
Don't stop yourself from learning new stuff, even old age like me in my 50s. Alrighty. With that, we will wrap it up. Thank you Vitor for coming on and making my head spin with talk of module federation. Um, and thanks AJ for coming. And, uh, if people want to follow you and read more about this or give you money or just hear your wisdom, where are the, where are the best places to do that?
Vitor Alencar (58:47.412)
Yeah.
Vitor Alencar (58:59.74)
Yeah, so you can find me in all social media. I have the same handle everywhere. It's Victor, my name, V-I-T-O-R, M, Alencar. So we maybe can share here, but yeah, right now I'm usually like creating more and more content. So you're probably gonna see on YouTube and LinkedIn. I think I'm posting there more and more. So that's, I think the best place to send me a message if someone has a question or wants to know more about anything that I do.
Steve (59:27.995)
All righty. With that, we will wrap up this episode. Thank you for listening, and we will talk to you next time on JavaScript Jabber.
AJ (59:38.678)
Cheers!