Lazy-Loading Runtime Module

[00:00:00]
>> Steve Kinney: So then when the app, the main app component fires up, you know, we can see that we have this, we can lazily pull in the remote component, that dashboard, right? And all React Lazy does is it wraps like an import and like we'll then like instead of including in the bundle, we'll go fetch it at runtime, right? Like if you don't write React, if you were doing this vanilla JavaScript, the part I have highlighted is all you needed.

[00:00:32]
All React Lazy does is then wraps that in a React component so that you can go ahead and like pop that right down here as a React component, but it's the effective idea of that import statement where we pull it in at runtime, and we hope it's there, right? But you can see that like this import remote analytics, like a lot of times if you were just using a monolith app, using Webpack or Vite or whatever, you could just import a file path, right?

[00:01:02]
And it would lazily, and it's a great way to like do tree shaking and lazy loading of your code. If you don't need the entire app in your bundle is 1 megabyte. Right, OK, like, let's load, you can do a lot of the like lazy loading principles in a regular application. In this case, that's not a file that exists in the host application that's registered in that manifest across both the remote and the host.

[00:01:27]
And then like when the, you know, when Vite or RS Build or Webpack or ES Build or what have you comes across this and has to resolve this, it goes to look at that module federation registry that we saw in the host app and it's like, oh, that's the one that lives at localhost 3001, or your deployed location. Let me go and pull that in and if you, you know, try to grab another file from that module, it wouldn't let you because the only one we exposed was this analytics dashboard.js, right?

[00:02:00]
And so now theoretically one could deploy a new version of analytics dashboard.js and you know what the app has to do? The host shell has to do nothing, right? Nothing. And there are some really interesting use cases for this, even if you have a simpler system, right? Like for instance, I will give you a use case that I experienced is RUI. It's technically 2 repos because open source and private stuff, don't worry about that.

[00:02:36]
Let's just say it's 1 repo. Is, you know, is the application. Right, but then we had a marketing website, but it had like a little bit of a different design language, so like kind of just do the old copy paste, it's usually good enough. But then we decided to put the sign up form on the marketing website, which should look and feel like the app. Right, and now, do you do the thing where do you do the build time version where you bump up the design system in the app, expose it as a npm package, then publish it to npm, then pull down the npm package into the marketing site, bump that version, run the tests again, or as part of your build process for the main app, do you take your components, bundle them up separately and put them on a CDN.

[00:03:28]
Right. And so like, are those two monoliths that happen to share a few components of the design system, is that micro front ends, I don't know, right? These are the things is like a lot of these things have weird permutations that just happen in reality for reasons without being fully one or the other. And so then like if we deploy like additional components or whatever, like they're getting pulled in.

[00:03:54]
I don't have to make two deploys every time I want to change something, right? So, like, there's use cases for this even that are even simpler in this case. Great. But so all right, we looked at both configurations, we saw how the manifest gets like published as a JSON file. Like if you look at MF manifest that I showed you in the browser, isn't in the code. Right, does anyone know where it comes from?

[00:04:20]
As either the dev dev server or the build process goes, it pulls in that configuration and it's producing that file, right? So it is kind of always, it's coming from the configuration, it's being exposed by the plugin. And so all of that kind of wires up as we go along. It's not necessarily a special file that you have to write. In addition, if you have those two config files, and like I said, if I, if you really wanted to be bored, I could make you watch me import this from RS Build to Vite and change like two dependencies and most of the code is the same, right?

[00:04:52]
You know, this felt like a nice ground so the Webpack people were happy and the Vite people were happy, so I kind of went in the middle in this case, but it's like, you know, you can use this with whatever it doesn't have to be React, it doesn't, none of this stuff is all language agnostic, but I had to write it in something. So here we are, and so you can pull all of those things in now we still have the problem that we had before.

[00:05:13]
So we talked about the configurations, we talked about the like lazily importing stuff. So even I could like, again, there are two dev servers running. I will, I can go into the remote app and we can go get the chart, for instance. And we'll turn this to. Let's start both of them to blue. And then we go back and now they're blue because I changed the remote app, but the host app is dynamically loading the remote app, so it got the new version.

[00:05:53]
I did not have, you know, imagine a deploy process. The host app did not have to deploy at all. We won in team autonomy. What did it cost us? Lots of like configuration and then like what happens if part of this app goes down? Right? You can argue, it comes down to like the thing about Wi-Fi. If you had no Internet, you would, you'd be annoyed, but you'd deal with it. You know what's worse than no internet?

[00:06:24]
Flaky internet. Flaky internet will turn you into a person you don't want to be. Right? And again, like before, if the, if the build, if you could not deploy because the build wasn't passing, that's not great. But it's not as bad as like 80% of your like app working, you know, because then you need to like think about, well, how do we gracefully degrade across all of those other things. If you just literally couldn't deploy until it was working, at least you know that once it deployed, it should be working.

[00:06:56]
Now it takes any given team having a bad deploy, right, and possibly the customer experience is degraded. But you can deploy separately, you won't get blocked, you can deploy faster, that one team can fix it faster. It's trade-offs.