Build-Time Composition of Microfrontends

[00:00:00]
>> Steve Kinney: Let's talk about the middle ground. So we talked about runtime, which was all the way on the pure autonomy. Everyone can deploy their things as they need to. There's some coordination that has to happen, so on and so forth. Right, like we saw that if somebody enforces a very strict React 19 boundary, then we have a potential problem, and because they don't share a build time, there's only one place to catch the error in the user's browser.

[00:00:33]
But you have complete, like, no team is blocked by another team. They can ship independently. There's like, again, like, and you know, thinking about like running the marketing site and the application site, like there was one team that doesn't want to do two deploys every time we change something. You know what I mean? Like we deployed, pull in that bundle with the state management that we needed to share and all that kind of stuff into the other app.

[00:00:58]
There's a lot of, even if you're not a full micro front-end shop, some of these patterns might be like, yeah, it's kind of a monolith, except for this one edge case where we have to go deal with, right? You can imagine like, you know, we didn't fully do it. I assume that the team I was on will eventually have to do it, but like, it is not unheard of to have whether or not you believe you have micro front ends or not.

[00:01:27]
It is not totally unheard of to have a doc site, a marketing site, and the application. Is that fair? Those might be three separate repos. Maybe you never even thought about that as a set of micro front ends, right, because those are three distinct properties. Now, play a game called How Long until either design or marketing or product or someone pitches the very reasonable idea that don't you think we should have the same navigation across the doc site and the main website.

[00:02:09]
Maybe even the application too, but it seems like a reasonable thing, right? And like having just one nav that you deploy, and they all get the nav. Whether or not you think you're running a micro front end or not, all of these principles and all these problems still apply, right? And so you're like, I don't do that, I don't have to pay attention to this part. You can imagine a world, right, like where like that might, some flavor where you just have to dip your toe in there a little bit, right?

[00:02:42]
And for very good business reasons, despite what you think. So the runtime part is really great because there's not a bunch of deploys you have to coordinate. The problem is you can't catch stuff at build time because there is no one build time. Right, so we can move back on the autonomy and complexity. It's like, well, if we had one app shell that everyone just registered their thing into, then we could catch everything at the one build time and we wouldn't have these problems.

[00:03:11]
And that's, yes, you have a new problem which is builds only go out when the app shell goes out. Right, because you have one build time. That's not a, it's hard to say if that's an advantage or disadvantage, that is the trade-off. You can now catch stuff at the one build time. Bad news, you have one build time. So like choosing if it's right for you really depends on the situation. The reason we're talking about this specifically is it's like a bridge from the micro front ends to the monorepos too, right?

[00:03:42]
Like, arguably if you had this in a bunch of different repos, it's build time micro front ends. If you did it all in one repo, it gets murky here, but you can have effectively a bunch of packages, whether or not they're on npm and you can basically tell npm or pnpm or Bun that they make believe these are packages, right? And it will do that without hitting the registry and have all of these in there and you kind of just say like, hey, resolve that to this other thing that we're using.