Episode transcript

Ryan Burgess
Welcome to a brand new episode of Front End happy hour. I'm not sure if it's just me, but I've been hearing a lot about module Federation lately. More and more companies are adopting these patterns to scale their front end code. In this episode, we're joined by Zach Zach and Dima, from Zephyr to talk with us about module Federation, how about the three of you give introductions of who you are, what you do, and what your favorite happy are beverages?

Zack Chapple
As you know, I'm the one with no hair. No, so Zack Chapple. I'm the CEO of Zephyr co founder. And, you know, just here helping to build the organization handle all the fundraising, sales, all that kind of fun stuff. My favorite happier beverage is actually right now I do a Jack and Coke. So nice, nice Jack Daniels in Bangkok. And that's my way to go.

Dmitriy Shekhovtsov
Okay, so mcg of there for many years into stuff like Google Developers, experts and up technologies that what I usually drink I regret now and will be much later because for me, it's like 11pm will be living with young man banana I'm planning to go to continue with rom color, whatever ROM in whatever color. So that's my heavy rig. Okay.

Zack Jackson
And I would say the, let's say, Okay, so I'm Zack Jackson, and I am the creator of module Federation. Also, Innovation Officer over here on Zephyr with these guys trying to you know, build this thing up. And infrastructure architect over at byte dance. Let's see my favorite. My favorite happier. I think it changes often. But right now it's gonna be the Moscow meal with Gosling's ginger beer Academy. Gosling's can't be anything else.

Ryan Burgess
Fair enough. I mean, you gotta be specific when you like, something like that. Let's good. And I'm Ryan Burgess, the host of front end, happy hour. Before we dive into the episode, I also want to let all of our listeners know, I've heard this many times from you all that we should do more video and publish our episodes on video. So in 2024, that's what we're doing. We have created a YouTube channel. So feel free to subscribe at front end. Ah, all right. Well, let's dive in. Let's start off with you know, what is module Federation for the people who may have heard of it not quite sure what it is maybe excited to try it? What is module Federation?

Dmitriy Shekhovtsov
All right. So the easiest way to put it is it allows you to dynamically import pieces of code from independent builds. So normally, when you think of a build, they're typically monolithic. Everything gets compiled into the one app. And if you say you have a header, and you have something else a homepage, you would build them together. And the header portion is probably what 15 kilobytes of text and the header dot JSX file. So now, in several cases, when you work at, say, on a big project, you want to share code, you can either go through NPM, which can sometimes get a little inconvenient to do. Or you could try to like, share it somehow at runtime. The problem is often you would kind of see these micro front end patterns, you know, come out and the whole idea was either you just have another bundle with the header there. And it runs as its own app. But the problem you kind of get with that is you're downloading a bunch of code you didn't need. So this was kind of the frustration I had when I first I tried to build Federation that was really well, I just want to import the five kilobytes that I don't already have, which is the user code. They typed in the header, I have all the other dependencies in my app, because we're all roughly the same stacks. So how can I just get the code that I don't have, and have that header use all the code I already have for it. So that's kind of the idea between Federation lets me share dependencies and export feature code similar to how you would do an NPM package. But we can do this at runtime, you know, on demand dynamically? Yeah,

Ryan Burgess
that's, I think you've described it really well. I'm like, I'm trying to think of anything you miss. I expect Zack, you know, creator of module Federation kind of makes sense that you've been able to answer that once. I think we can cover some of the benefits to of module Federation, like I know, something that my team was doing at Netflix was we owned a platform essentially, that other teams were building and integrating in. And so one thing you could do is like, Okay, everyone just, you know, writes code in the same codebase. And that's one way of doing it. But that's somewhat limiting. There's some teams that are like, well, I want pieces of my application does show up there or I want to be able to deploy and be independent from everyone else. And so leveraging something like mod module Federation made a ton of sense and it allowed us to really create One application but have various teams integrating. And so that was one thing that right away that we're like, yes, that's a really great use case for Module Federation. But I'm curious, what are some of the benefits that you all have seen from leveraging module Federation? Speaker 1 One, I can jump on this one too, because there's some fun stuff around, like build time, right? If you're building a giant monolithic app, and being able to decompose that into federated remotes, I think that's a really nice thing for developers, because like nobody wants to sit there and wait for a build Dimas talking about back end develop, like, I was doing development in Java, like, go get a cup of coffee, because six months later build might be done with UI like the same things happening to so being able to decompose that into federated modules that you can build independently, even if they're all still being built on your machine. You know, being able to do that independently, I think is a huge Yeah,

Dmitriy Shekhovtsov
I would say probably one of the big ones that I found is useful for it is it allows Conway's Law to keep living. I mean, really, that's kind of what it comes down to. Conway's Law at some point is going to kick in, and not all deployments, I would consider equal. And so this is a really big problem, when you have a monolithic app is you know, you want to fix a typo, it's just as much risk as if you were to, you know, go rewrite an API release from the product side, when they look at it, you got the same rigorous QA, all of this over, you know, pretty much nothing but nobody's gonna let you jump to prod because you know, you put a space in, in a word that shouldn't have been there should have. But so with Federation, it really allows you kind of break down the categories of how important a deployment is, what can be shipped with less rigor, versus what really does require that and, you know, putting everything into a single monolithic application, be it like, even if you tried to do mono repo and split this up there is at some point, you're going to find some company that has compliance problems, well, illegally, we cannot keep that code in facts to this other code. Like if you go to the bank, or if you're in the government, or if you're a company. You know, under scrutiny, it's very tricky to just put everything in one place, you need to really be able to control and separate all the concerns correctly. But now, if you do that, sorry, if you do that, you then have the problem of how do I still like move quickly and work well in it? So yeah, I would say like, those are really the big enablers I've seen, it helps to enable the team, but also do like the pattern that Federation kind of forces you to think. So I found even with companies, they say, Hey, we might want to use Federation. But we don't think we need it right now. I will say then cool, do mono repo, but pretend it's going to be federated. So now you don't have these all these weird cross enforce between the mono repo and it doesn't end up just being a giant Simulink model, you know, monolith and not actually something that's composable, just kind of put some guardrails on it because now you know, well, hey, at runtime, I wouldn't be able to do that. So for pretend it's like that you generally end up with code that's actually better isolated. So do like the pattern of it physically separates the damage that can be done to a certain aspect of code. And that's very easy to run wild. And when you know, there's just tech debt everywhere. Like if you're in the old monolith, it's very easy to add more tech debt to something that's got six years worth of tech debt and product doesn't care. And you know, this is pretty much just a dumpster fire that's eventually going to implode anyway, so why not just keep gathering more often. But if you have a new repo that's nice and clean, and it's just header, that header is probably going to look a lot better, compared to wherever it would have had to go in before. Because now you can control more, that team use something a bit newer, you're not necessarily stuck with all the old practices that came in the original code base.

Ryan Burgess
Zack, are you saying it's easy enough to to like take that six year old mono repo and then decide, I think we're gonna want to go module Federation at some point and start to like, head down that direction? Or is it more like, hey, we have this brand new code base. It's a mono repo. And we should start thinking strategically, still quite difficult.

Dmitriy Shekhovtsov
So I don't I don't know if I've ever done it just like one off and see what happens. But in theory, if you wanted to just do the complete flip, even if you still had like a single monolithic build, what I've done to test this out is I just say okay, well, for every mono repo workspace, I'm just going to add a new federation plugin onto the main build. So I'll have like 27 Federation plugins coming out of one bill. And now I effectively have a mono repo at runtime. Each one has their own scopes. Each one has their own things they expose, they'll have their own package names, and I can import and use them just like I would have been doing in the mono repo. But I think the challenge there is if you take something like that, it's like well, if there's all these weird crossovers between them, what's that going to do to your reliability and kind of separation of concerns? turns on blast radius and so on. Because I think even with microservice, that's kind of the big reason we try to do it is one that helps to break down the blast radius, if something goes out, you're not going to take the entire company down only maybe a certain feature. So inside of your codebase, you generally want to try to follow a similar approach. But if you wanted to do a direct port, the experiences would probably be quite similar. But it's more about the building software that's resilient, which I think we should say on either case, it's just in Federation, it's something you want to think about further, but I've generally found that by doing that, you'll wind up with less less of ones, because you've generally spend a little bit more time thinking about the unhappy pads of the code.

Ryan Burgess
I'm curious, like, I think we've highlighted quite a few good benefits to leveraging module Federation, with anything out there in software development, there's always trade offs. I'm curious, what are some of the limitations with Module Federation that you'd be like, yeah, there's that could still be better. Or maybe that's not the right use case to use it for, Speaker 1 I got one piece of that config file and configuration boilerplate, not everything to go along with that, you know, having to maintain the URLs and you know, the shared scope and everything that comes with the federated remotes. I think that's one of the things that I've seen in social media, and you have support requests. And, you know, I keep getting this, you know, what is it the eager fetch, you know, issues around? I think that's one of them. So far, I think those are, those are roles that we can work around pretty easily. So she wouldn't have the credit, you can you can talk to. Yeah, that makes life a lot easier. I think that's that's the.

Zack Chapple
So I suppose that Samsung, we call like dependency management on our end, right. So like, for those who have not been like, playing around his model Federation configuration for each input, like if you want to import a remote, right, you kind of write one line of code on your side of like a compliment. But again, on the configuration part, you have your production, staging, development, local environments. So for each remote, you have four lines of imports. So if you have like 20, remotes like it's only 15, roses, some companies, you haven't got, like configuration, which is like 100 lines of code just URLs. Then if you're working in most likely or working in distributed teams, there are fun times to understand when somebody has updated remote containers, when they're going to bring something on your table, which wasn't expecting to have, because one of the benefits of moderation. Pros and cons, obviously, is shared libraries, which allows you to reuse not only remote containers, like some piece of code, but actually makes things smaller. So if you have react, and it's used all over, like all of the 50, like containers, you'll know that once, but then they're like dependency resolution in terms like, we have react 18 1617 And whatever, right. And then somebody in some other country actually deploys a new remote, and it uses different version of React and breaks parts of your application. Luckily, you have like React clays in suspense, you can like limit limit the amount of damage he's gonna do. But still, it will be interesting to like, find a moment of time, when there was that change actually happened, I already been able to like, you know, package lock your dependency on the remote container. Because like, we get to use to some kind of level of control over our dependency thanks to NPM. Right, we get used to it, we can said what kind of updates we want to get, we're gonna have like package, we always want to get same versions until we manually do like bump the versions and do comments for that. So we get used to some developer experience, and because of the nature of containers as a change over time, and they have different environments and different streams of updates, like obviously, you do expect eventually to have a versions available at the same time. Because it's something like, like, actually requested for. And there are other things which I will give word to Zack, because it's something she loves, because people want to want to have more granular control over a lifecycle events Speaker 2 for moderation. And that's something that can tell even more. Yeah, I would

Dmitriy Shekhovtsov
say, I think a lot of the downsides of Federation were around like what I had originally built four years ago, and I had experienced a lot of these downsides as well. And we ended up now kind of trying to resolve most of them that we could I think there's always an interesting kind of challenge that gets anything in kind of software architecture, or anything in this kind of stuff is like okay, there's you can do so much to solve the community issues and But you can only do so much as at runtime with a static build and with no close source of intelligence in just a distributed system. So I can make the Docker container much, much better and make Docker compose really, really good. But effectively, at some point, I'm not gonna be able to build Kubernetes, with Docker up, like, I'm going to need something else, if I'm going to really scale this thing far. That doesn't mean that you can't improve what the containers can do and make a lot of the issues that have existed go away. So I think the biggest thing that we introduced really was the was a lifecycle hooks setup. So it's essentially a way for the user to be able to write small little runtime plugins that can invert the control of what Federation does, because I know a big one is like, well, it's a black box, we don't know what it's going to do, how it's going to do it, we just know, it'll, it'll execute. And so the introducing the lifecycle was really to try and just put some other general eventing on there, like so you know, some of my favorite hook that we've added is error load remote. So this is a question we get all the time, what happens when the container is not available. And it's offline, that'll take you that'll hard crash your application, even if you use a dynamic import, because it's web pecks runtime, checking if the containers there for it to run the factory, and it's not so it can't go and get, it's not an error on getting something out of the container you ask for. It's the container reference doesn't even exist to begin with. And that causes a hard error. So you know, things like that. So we introduced error, load remote. And now if something crashes, you can return your own module, exports of whatever you want. So hey, if header is an online dynamic import stale copy from NPM, and load that in or repeat the cycle, and here's a different URL, try pulling it from the stage remote, or try pulling it from origin V. Or, you know, hey, if you're using local hosts, and local host is an online, then just cool. Go go to the next one, go to the next one, keep going up the origin. So you find somebody who's available. Another really big one that we had. So within there also was like dynamic remotes, or how do I configure the URL dynamically, I can statically import whatever I want. But nobody really had an idea on well, how do I change the URL on the fly. So to do that, they would, you know, fail all the way out to like the library mode or Federation, which is more complicated to work with, because you have to initialize the remotes yourself. And, you know, it's not very intuitive to work with. But what they really just wanted to do is they wanted to change the URL, you know, depending on what the window h ref was. So they'd have to like over engineer the solution, just because there was no way to do it dynamically. So we've introduced you know, a series of things like before initialized so you can set up all the Federation config, who the remotes are aware before anybody starts running. We also have hooks like crate script. So if you want sub resource integrity, or nuance or something added on to it, you can return your own script element. And we'll use that to load the remote entry and everything else. Another really big one that I think this was the biggest challenge we've had is, is caching was not able to be deterministic, because of the module sharing, I can get react but where I'm who's gonna then react, I'll get react 18. But I don't know who's going to serve it to me consistently. And that can be a bit of a risk issue for companies, when you say, hey, well, your dependencies will be a version that you asked for. But we can't guarantee the behavior between executions, that will be the exact same branch that ran first. So we've introduced a another lifecycle hook called resolve shear. So basically, that allows you to take over the resolution algorithm. And you could say, well introduce a few runtime plugins as well, so that you don't have to go and like, figure them out. But most of them that I've written have taken like 15 minutes, and I can do practically anything that you could imagine. But what I'm what I want to do is bring out like a results share, plugin, just where I'm just using the hook. And then I could say, well give me your preference. So when asking for React, you should always prefer the host if they haven't, and it's within range. Or you could create like a common vendor remote. And now everybody could say hey, if common vendor remote exists, prefer them for loading these dependencies, otherwise prefer the host. Otherwise, negotiate amongst yourselves and find an ample one. But now you can introduce you know, full lock files of everything I know, you can force it to always use the vendor remote to load react, no exceptions ever. But if the vendor remote isn't there, there's no central point of failure. Unlike, you know, with DLL plugin or ESM, import maps or whatever you do if the resource isn't there, you are done. In this case, it's like cool, let's just try one and we can repeat the cycle endlessly until it you know, finds the right thing but you're in control of that. And if you don't care about any of that, then don't worry about it. Just Use it as you want. And it all keeps working. But the second you need something, you've got a very simple little API where you can, you know, stack these things, and we ship a couple of them as well. So yeah, I think the runtime API will help with a lot of the drawbacks. I would say the one drawback but still exists will be it's very hard to tree shape, shared code, not exposed code, but shared code. But I think this will I think, anything you go into distributed systems, you're probably going to find the same issue. So imagine if you're using like, now.esm.sh, no tree shaking. If you know, if you're going to use import maps, there's not going to be tree shaking. So regardless of how you get shared code, if it's shared you, you're gonna have a tough time trying to tree shaking, but that's definitely a you know, a downside, I would say,

Ryan Burgess
um, it sounds like there's been a lot of flexibility on it. Like all the things doc that you just talked about, it's like, Okay, here's some of the problems we were seeing out of the box. Yes, it's going to work. But there are these nuances where you want to have more control. I love that even, you know, trying to find like the if something's failing, like, what, what's your fallback? Like, that's what I took away from that, too, is that you can start to really think strategically about what's that fallback look like? And then module Federation is smart enough to say, All right, this isn't working, I'm just gonna go grab this, like, you know, build NPM package, whatever it is out there as the fallback. So I'm happy to hear that. That sounds really cool. Zach, it also sounds like there's some new stuff coming. Like I know, module Federation is an ongoing project. I think there's a new version coming out, what are some of the things that people can be excited for in some of the updates,

Dmitriy Shekhovtsov
so we just dropped the the first part of it, which is the enhanced plugin. So if you use webpack, and be at module Federation slash enhanced, looks the same as it always had, except there's a new field called runtime plugins, and it takes an array of you know, require results, and gives you the runtime plugins that kind of discussed, we also just pushed it into RS pack. So the enhanced plugin is the default and RS pack. And all of this just comes right out the box, which is really great. We are adding, so we have still in the works. We're gonna have type scripts type thinking. So you'll have remote type hints, sometime this quarter, you'll have real fast refresh and hot module reloading this quarter. Let's see what else have we got on there, and we're bringing out a documentation solution. So basically, every remote module, or every federated component will automatically build its own like storybook code sandbox. And that'll be a side effect of just doing your normal build. So if you just put the, you just enable module doc, that's the end of it. And it'll just create another remote entry called remote entry dash doc. And they will if you have a way to crawl like all the other ones on the page. So you could use other things that are API or whatever. But you could say like, rotate the page 180 degrees, and pull all the remotes connected to the current application and generate like a distributed storybook on the backside of the app. So you can say like flip it around. And there's a storybook where you have a code sandbox, and each component, its docs, you can interact with it just like you would with like a storybook or whatever, but all of its distributed. And, you know, I think all you have to do is just added dot MDX file. So anything that you expose, just put a dot MDX and write your MDX and it automatically cell forms it stitches it all together and everything else. So we have type hints, hot reloading, we're going to have better Server support for busy working on that right now for QA common Jas, we're working on ESM support for the node side, it's a little trickier. I'm hoping that maybe this year, we might even introduce import maps. So if we're going to do some port maps, then with what we're doing to Federation is we're trying to say it's no longer a Webpack plugin, or build plugin. It's a it's a code orchestration framework, or whatever you want to call it. It's a dependency manager at runtime, that that has compiler plugins that implement its runtime. So like right now, Webpack and ours pack implement the enhanced runtime and provide it with some data. But the rest of Federation is effectively a library. So the idea is, is well, the only thing really that the bundler is still giving us is splitting up the chunks and telling us the references of who that chunk is and where and if somebody asked for React, it's actually over here and wait for that. But, you know, with how we designed it, we should be able to replace one piece with a import map Bundler runtime, and then just say, well, instead of writing to a shared JavaScript object, translate that into HTML element. So if we did that, then it would kind of provide Federation as a, you know, web standard compliant but much better with Bundler solution. But then, you know, that would give us that agnostic option similar to what single Spa has and then I know Oh, let's see ducks. There's a lot of things happening, but we've got ducks. Some Chrome extensions that we use it by dance are also going to become public. So you'll be able to kind of see what's going on in there the typography. In Zephyr, I think there's some inspiration that flows back and forth between the two groups. And like how some of these things could work because we also have a very similar setup to what Zephyr is. So we'll be seeing some chrome extensions come out of there. And then one interesting one that just took off now is we're looking at possibly adding a router somewhere in the mix, saying that Federation could be a full framework, if you want it to be of you know, it's got a router, like single spot kind of has that router could feed into our runtime hooks. So now, when you're saying, you know, before load remote, you could know what the route is what the args are in the route, all of that stuff. And you could potentially have your module logic gates know, your router data as well prior to the app even booting. So I think that'd be very cool to have that look ahead. Because I've had tons of issues where if I knew where the app was going at startup, I could do something about it pre loaded or something like that, but usually have to wait for Jas to kick in and everything to happen. So I think it's very interesting to be able to potentially have the router information before Webpack is done booting up. And you know, like as Webpack starting up, it's got a router in there that passes into your framework. But you know, the very, very interesting way to make a look ahead of it. So anyway, I think that's kind of what we're trying to do with Federation is the way it's been built. There's a lot of really good stuff in there. And I think regardless of what you're building with, if you want to share code, the problems are guaranteed gonna be the same. So whether you do import maps, or straight ESM standards, or you doing Bundler magic, like we should generally have done, the problem is still gonna come that well, when the when the shared module isn't available. How do you recover without crashing the application? How do you, you know, how do you know where to load it, it's always the management of it, it's not really how it's managed. That's the problem. So we're trying to take Federation and push it more in that direction. So that cool, this manages code, whatever code and how it gets it, loading the script has never been the issue. 10 years ago, we could do the same thing it was managing, said loaded scripts reliably. This

Ryan Burgess
is all impressive. Like you're just like nodding along of all these really cool things. And funny enough, one of the things that really got me excited, especially thinking about multiple teams trying to build and work together on things. I mean, I'm just gonna say it as engineers, we're often really bad at writing documentation. And that documentation, I think, is really critical in these scenarios, because you want to better understand what the other team is doing, like, what is that components supposed to do? And like, how is it supposed to show up? And for it to happen more automatically? I'm sold, right? Like it says, you know, easy to forget? Yeah, yeah, we'll get to the documentation. And you know, you do that a couple times. And it's you're so out of date. But if this is happening behind the scenes, that's huge. And being able to see the whole application that way. I've just That was impressive to hear. I think that that was something that even my team at Netflix, what we're working on, that was a problem or concerns that we were having as like, how do you keep that all up to date and have the bigger picture of what the application is? So really cool to hear that. I would also be curious that you all I mean, all working on Zephyr, which is, you know, definitely a new new thing that's out there. I want to hear a little more about that, like, what, what are the benefits of Zephyr and module Federation? Like, how do they come together? Why would I or companies want to leverage Zephyr? So

Zack Chapple
what it was speaking about, like motivation, right, right. Pros and cons, and mostly like things which are hard to start with, right? So most concerning ports are configuration, dependency management, and where dependency management is their version control. Right? So therefore, I'm looking first board, like, you need to be able to jump into mode of operation as simple as possible. And let's be honest, there are two parts to issues with documentation. Right? One issue is nobody wants to write documentation and other issues. Nobody wants to read documentation. So like, let's be honest, like, if you're an engineer, you want to like write two three lines of configuration and make it run it right. So that's why when I was like, that 40 to you and like, there are just one line to it for any application alteration or not. Right? It's a great start, like you have you do nothing. You get clone the NPM install, build, you have a deploy, right. That's easy. You did it for one application for another environment repo. And then you have to actually remote in the name of from the next file to you. And those are already connected, right? You don't have to provide no like shared libraries, configuration and no like, depends on the resolution where it's going to be deployed. You don't really care because that's done for you like things, which takes a lot of time, but we don't think about it because it's part of our kind of no obligation is like create, see ICD processes, create environments, maintenance of the environments, and be responsible for like bumping versions, and like code reviews and stuff, right? That's actually what it was spending our years of our life on studying how to do develop properly, stuff to actually maintain, even which are not super interesting, takes huge amount of time. And that's, like, we want to solve interesting issues, things which like, LGBT cannot do for us. Something like that. Right. So that's something which is like developer experiences, model Federation should be closer to what we get to use to ism PM, because like, making today's like, like seven years ago, it's actually it was seven years ago, when NPM wasn't super popular, like maybe nine already super old, right? When he was like installing some use clothing. And he could see 234 package managers in one repository, and you have no idea what you have to do, right. So right now you're looking at a visitor, you see a log file, you see your luggage lock, or a yarn lock, or can pm look, and you exactly know what you're going to run. Right? So I want to see same level of, you know, how easy is to start with one operation, super easy. Just install Zephyr as one liner here, one liners are everything deployed. And you have versions you have your side panels from where you can switch those versions is your updates to go into application. And you can visualize the dependency between models raishin, because other parts of manipulation, which makes it hard. On one hand, we say like, Okay, we are developing distributed application, independent parts federated for your house. But to understand how they're actually connected, you have to open each one, open and configure modal Federation configuration on each one. Take a look like your eyes. If you're lucky, if it's just your right, there could be like delegate modal promise, new promise, this amount of code where you have to find how that's connected, understand how this works. And then in your brain bill, like your graph of how things got to be connected in runtime. Right. Sounds really a problem. So I think this is

Dmitriy Shekhovtsov
this is even an issue beyond just Federation, any distributed system, the observability and the the ability to see the topology of it even in a standard mono repo beyond NX. I can't think of anything else that could show me how, who uses heter. Like, even if you're if you had two mono repos, how you had her team could not understand where am I used everywhere? And what is the spread of how I'm used and in which file Am I use across the entire company 1000s of repos, a hundreds of repos or one repo, I want to know the version of use that and the very line that I'm implemented on. And you just can't do that with anything currently that I know of, other than maybe annex four packages. But as soon as you get into distributed systems, you lose a ton of visibility. And front end just happens to be a place where you know, the disaster can be worse if you can't clearly see what's going on. So it but you know, this is a problem everywhere. So tackling this is you know, I think a big part of it. Speaker 1 When talking about it's the instant blame game to the somethings that something goes wrong. So like, you know, production goes down who broke it? Is it the last person that poached or someone that pushed away to go on their journey, this just happened to get in bundled into that deployment, right. So I think that's the the other interesting thing about like, module Federation is like, a lot of organizations that we see, they're still in a state where everything is evergreen all the time. And you have no idea who actually put something that broken, right. And you combine it with the fact that a lot of people aren't defensively programming, and they don't have suspense around their emotions, they don't do a lot of those things. It makes it very quick for people to get taken down. And I think with with Zephyr, a, having grown up knowing how all the pieces come together, and being able to control the versions of each of those remotes independently understanding the errors that are there having the performance obligations or having I think having a picture finally will make, you know, module Federation, together with a lot of stuff coming in 1.5 really ready for your average developer to be able to feel comfortable with not require someone who's you know, really deep in understanding a distributed system. It's going to lower that barrier of entry for a lot of developers to be in developing and working in this kind of system.

Dmitriy Shekhovtsov
Yeah, and I would say even like she's speaking a bit to Zephyr specifically. So Apart from Federation, I think there's kind of two interesting tracks here because you have Zephyr, which has this great log file for managing Federation and deterministic cash deterministic way.

Dmitriy Shekhovtsov
the other angle of it is as well, you could probably do like, we could probably make this work of saying NPM package too, because if we can stably manage applications at runtime, switching versions, controlling your shared code, all of that, then, you know, doing that at build time is definitely not as open heart surgery is doing it at runtime. So even if you want a monolith, I think still same issues apply. Who uses it? Where is everything in governance? Is everything in the place that it wants to be? And do I need 25 tools to try and get an idea of what my application is built of and from, and how can I manage that easily. But imagine going in changing a drop down and saying, let's use a, you know, new version of lodash. And all we do is we just send a web hook and say, Whoever this controller is just kick off CI again. And you could even use Federation and CI because node Federation works. So you can actually generate the worker, the workload code, manage it for your CI on the fly, which is kind of interesting. So I see a lot of really interesting opportunities just in making this stuff easier. But I think ultimately, at least in Federation, kind of the vision that I'd had for a lot of this stuff is really the build as a side effect, or the deploy as a side effect of the build, I don't care about the deploy, I don't want to know it exists. After I hit save, my job is done. I don't want I don't want infrastructure, I don't care how infrastructure works, I don't want to look at AWS, I want to press save and go on to the next thing. And so I feel like this is this gets distilled down quite nicely into Zephyr where I don't even I just punch in my key, it'll configure the environments on your cloud, not our cloud, which is, I think, a really big selling point of it. But other than that, like cool, if you can compile it, you have deployed it. And now if that deployment is guest facing or user facing or not, that is just a switch on the lock file that we're sending. But effectively, every safe press could be, you know, is the same as an ephemeral environment. And, you know, for me, I think that's the dream, I don't care about how it builds, I want it quick, I want it done. And you know, I want to be able to get things I want to speed up the feedback loop. And a lot of the feedback loop does not occur locally, I have to push it to a server where there's the right data or where there's QA or to collaborate with somebody. And if it takes me 45 minutes to do a single build, I can have my fastest iteration between me and the quality section of the team or whoever wants to look at this, maybe I can do it six times a day maybe like

Ryan Burgess
that, there's gives you a lot of flexibility. And just like, Zack, I think both of you said this of just, it removes some of that, like, I don't want to deal with that I don't want to deal with releases or worrying about that. It's like I just want to like get my stuff done and see how it works and move on. I think that's so powerful. It just is removing a lot of that complexity. I'm curious too, as as companies are starting to leverage Zephyr, what are the benefits that they're seeing? Like, why what's compelling to them? I mean, obviously, a lot of the things you just said, I can see that. But what are some of the reasons people like yes, I need to have that integrated in my system.

Zack Chapple
So I think one of the fun ones is something we experienced ourselves using it, you know, so Dima is frequently letting us play with. And we ran a zoom call. And he was in the process of intercepting Central. And as a developer that's at its entry before you know, you have to go to St. Paul's, you know, open a PA jet, wait for 1520 minutes, like, and then you know, you'll see it in your environment. And then you'll start getting and because of the ability of Zephyr to take an environment and bring remotes to it. Really exposed to that. And we were able to see what he had just saved on his local machine, live on the edge in a staging like environment and start getting sentry errors almost immediately. And it was, he's like, I can't go back to regular development, like everything is instant, on the edge, I just, you go look at another project that doesn't have Zephyr and you die a little inside because it's just not as fun as you know, the instant gratification of everything else. And I think that that's going to be something that is going to be kind of addicting to people and it won't be a question of like, you know, what are you doing today? It's like, why aren't you using these efforts? It's like, why am I doing this in this day and age and having to wait for infrastructure to wait for the stages to get to the point. If you get developers used to instant gratification, that's gonna be a dangerous world.

Ryan Burgess
I mean, we've had lots of that just over the times of even like live reloading. It's like one of those things where you're like, what once you've had it, you're like, I need that like so I can totally see where you're headed. Don't that Zack is like you just get used to it. And you're like, I don't want to go back to not having

Dmitriy Shekhovtsov
that's been the experience we've seen with a lot. It's like somebody use and they're like, yeah, there's just no way. I'm gonna spend two hours doing what I did in five minutes again, which I mean, fair I was, once you taste it, I feel like okay, cool. I just can't go back on. But But yeah, you know, I think it's gonna be, it's gonna be exciting to see what like the bigger user base thinks of it once they get a chance to try it out. And we're quite excited to see what kind of comes out of this. But I've also found like some other really cool ways to use this, because sometimes we found like individuals who don't really want to go all in on Federation, because they're worried about maybe a business impact, or maybe the final performance, because if they need to share like a loop, they share material UI, and they share it poorly. So you get 25 megabyte chunk, because it shares all 12,000 icons available. Like okay, well, maybe you don't want a mistake like that to happen, I can fully understand that. But I've also been looking at well, you know, with his effort with the control over the builds, like we have, with the new stuff that we have in the Federation, one five and stuff, I also don't see why you can't use this as a hybrid solution as well. So to go to production, you got to do an old school NPM publish install 45 minute loop. But the rest of your development cycle up till time to go to production could all use at runtime linking, oh, here's the new header, blah, blah, blah, okay, when we want to go to production, we're actually going to install the header up to that point, we can just stitch the header across the wire, iterate on it, make sure everybody's happy and speed up the whole development workflow until we get to production and then do one slow, you know, immutable artifact delivery. So I think there's a lot of ways where you can really use the workflow to speed up like the mundane parts of it, it doesn't always have to be all in. But again, you know, not all deployments are equal. So do I really need to wait 45 minutes to see a type of fixed and header for QA? Or can I see that in a couple milliseconds, and then I'll wait the 40 minutes to put it into production. But how all of our C eyes are typically structured, everything is the same level of importance, and you're gonna have to wait equally, which, you know, I really don't like that way, the important stuff should be behind gates, the rest of it, unless I'm planning to push it to production, you know, it should always be like on like, I don't know, intend to merge checkbox, then all your gates kick off, and then it takes a long time. But until then just get it on s3 as quick as possible. And if stuff fails, delete it from s3 afterwards, but get the code available. And let all the quality gates go green, which allows the lock file to update in the right environment. But like in Zephyr, how quick, can I get the string on the internet so that you can use it. And then if you're allowed to use it or not in production, all of those are artificial gates. They're not anything that needs to really be done. It's stuff gates, that cool if the unit tests don't pass, they can't go. But if I don't care about unit tests, why don't need to wait for them to run, only care about unit tests on like the last five commits I make over whatever I'm developing, then I'll actually look at CI until then I just want to get it up somewhere and look at it. And then eventually, I'll actually go and do the cleanup. So you know, I find that pattern much better. I don't care about any of this cool, well, let me put it in production with anything red. But until I actually want to take it apart. So

Zack Chapple
like my takeaway is like Zach ties for a good topic. So to set up a local environment to work on your feature is going to be really painful. We have seen environments where you have to like run five, six wrappers with Dockers all connected and like bills for two hours on the best machine to make a change and like to change the text somewhere, right? And these kind of things like alliteration and Zephyr, I don't have to do that anymore. Because I can run a little hard time working on another one like Run Run like serving local machine and right environment variables, right? Because that's actually connected to your build environments that can actually feed your environment variables for where you're, where are you planning to look at that on a dime of a built from cumulus storage, whatever. And what is the most important for me, like, I've worked on the part of the code, which actually will fix an issue on a production. But I will have to go through several different environments, which doesn't even have his own data. Right? Where you'll have course issues, he will try to do that. And with Zephyr and low vibration, what I can do, I can just run that stuff locally, and not even set up anything like in particular complex how to replace the VARs that particular container in production, which obviously can attach from a local machine, right. So and like, usually, what would take me hours will take me minutes just to like run and build. And like what you build is incremental deploys, which is under a second. And that's going to be running in production with production data. And it will be able to say that this particular thing actually fixed an environment we show us and it's intended to me not to go through like several stages of something and it will be landed in two weeks when your sprinter done. Right. And that's actually totally like amazing because similar similar level, which is actually still available to everybody, similar level of developer experience improvement was when we have seen the spread of usage of revenue environments for your prs. Right. And still, not everybody use it. But that gives a huge boost for QA. So like if you're able to work in a local environment and deploy to staging environments directly, because what they need to do just see like your combination of remotes, and being able to run, actually, automation tests on staging environments with staging data, but as your container without any like, drawbacks on performance whatsoever. That's huge, actually huge. And one of the scenarios which I heard like, and I enjoyed the most, maybe, as well, people said that when they did acquisition, and they do acquisition a lot, right. And they then they spent several years natural to write that application and technology to begin, like to make it a part of like, I'm trying to use a word which Phil, like, reveals, enabled, like the company, but like, there's a common marketplace of the application for the Reza use, right? Like, you buy the new spend several years, this product, maybe not really actually, like interesting to market anymore. And then like, if we go to like alliteration, we're able to inject the first page, like several weeks from now, right? Because we can pick the parts, make that a separate application, deploy that immediately. And with Zephyr that's most likely goes from weeks to days. Right? Because you don't even have to like, think about like, what is going to be deployed, how does gonna be orchestrated how to inject that stuff. Right. And this is, like, from years to days, that's a huge, like, game changer is like, from what it was, like, if you remember nightly builds when you didn't change, and then you have to wait overnight, then in the morning, somebody else has pushed something wrong. It's it's the same experience we have currently with like, our development PRs, right, we work with that. And like, then we are waiting for that everybody thinks they're issuing some rain before we go to muster. Same thing here. So that's actually something which excites me is the speed of bringing new business value to like products without being blocked by the things, which doesn't really matter. Overall, they gotta be running there, you will still have your like, green checks. And because like each build, each commit has independent candidate, if you're, even if you're going to run double this change later, or you're in Thailand, or like whatever, they can be connected now, because we are not deployed in a bunch things. Right. Now the backend of the zipped folder, each change has its own identifier. So like, you can connect how your particular work has changed the performance of the UI, and how much actually like business going to get from that, which is great. And it wasn't simply available before. So that's something I really enjoyed to see, to become more used. And like, we all I believe that's going to be like great developer experience change. So like I was like working for.

Ryan Burgess
So a lot of what you all have highlighter, just like what I hear about Zephyr is just like it's it's a pretty big productivity with like, I that's what I see it as, I think, a lot of benefits there. But yeah, just being able to get more insights into an application or even polling, like, I didn't even think about it of like a company that has an acquisition of another company or you're pulling in another team. Like, that's a lot of work, there's a lot of complexity. And if Zephyr is able to just cut that down just a little bit. That's huge, and just being able to pull things together a lot faster, and just giving more visibility. That's really cool to see. Now, before we dive into pics, I would be curious from each of you of if someone's wanting to adopt module Federation or maybe a team is wanting to adopt it or leverage Zephyr what's a one piece of advice that you would give them

Zack Chapple
Sorry, I probably still do is but use an X. Yeah, seeing in terms of one of the things that we found back when we were doing consulting is, is leveraging something like NX so you can create generators and migraineurs and things for your team to bring some of that consistency. Now granted, having Zephyr will make some of that, you know, obsolete but if you're not using that for having those like NX generators that will generate consistent applications for your organization. I think it's gonna be pretty cool. And then like you heard the litany of things that you know Zack is releasing and one five, having you know, annex migrations to be able to upgrade your stuff from like, the delegate goes to, you know, start leveraging the new hooks and stuff like that will give the organizations that have architecture teams do a way to programmatically upgrade all of their poly repos. Leveraging annex is a very good way to do that. and also just the guardrails and the things that they're building into supporting annex already marked the Federation enacts already is extremely helpful.

Dmitriy Shekhovtsov
I would say, don't use the Federation plugin that ships in Webpack. Use the module Federation enhanced plugin, because Federation is now no longer in Webpack, but the original plugin is still there. However, anything new is not going to be built into Webpack or locked into any Bundler. We will be building that under the module Federation universe repo. That's the point of truth I would go to WWE Federation enhanced is the plugin where you get the API's, the slickness, the all the new stuff is going to happen there. It's backward compatible with whatever web pack has. So they're interoperable. You can mix and match. But if you're starting and you're working on it, definitely go for the enhanced plugin. We pass all of web packs tests, we pass all of our s pecks tests, and all of our Chrome extensions, all of our ecosystems will drop in and work with that new runtime API. So and give the READMEs ago, and we'll have a new Doc site soon, which should help make things easier to understand and navigate some of the additions we've made.

Zack Chapple
Like my third purchase, I'm even more lazier engineering teams. So I have abstracted away from my limitation. So pretty much I'm just with Zephyr, and depends on the words used, I have a different implementation. So if it's like just a client side, and we're back, I missed one more operation. If it's an if it's like next year's, it's going to be another implementation. And in the nutshell, I'm going to use reserve for for just no GS application and like to achieve infrastructure list. So pretty much like with Zephyr for me something to go with model Federation, or just the Federation of things. Because like when we speak about model Federation, that's, that's a term that you're going to we'll have to change over the time. Because with the granularity, which we have, as our Spark is lifecycles, that's going to be like function Federation, or components Federation. And it's not a model anymore. That's some units of work which we can fit, right. So pretty much we are able to federate not only UI parts already, we can federate streams, or react servers, compass server components, right? Those are not not models anymore, right. And we are able to catch them on different levels distributed in different levels. Like that's a completely new area, which is coming here. And there will be in demand tools, which makes onboarding to the things easier, because let's be honest, like, I know assembler, I was starting to use assembler, like, almost 30 years ago, right? Now what it is at a higher level obstructions. And like, most people use code pilot, because you don't want to spend time on something like this. So like you start with Zephyr, right. And then if you need like some super special, like going into like details. In there, you're gonna find out more information hands, which provides you a lot of capabilities if you need something which is like, not sounds like common. And but that's like, you know, you eventually mastering the way how you do like perforation, it's not that you have to jump into documentation to read all of that. So like, don't try to, you know, eat the world when you start his mental operation start small and enjoy the process, because there are huge opportunities out there. And it's actually shaping up really quickly. And I do enjoy how does he that does, I hope like people should enjoy the journey of exploration because they are seen in new era in like development, that hasn't been happening for like last 10 years. So the last big change, for me at least was like Docker and Kubernetes. And like console, like hashey Corp actually was the things for Beckett quite well. But just thinking about it. That was 10 years ago. Next big change which heaven for kind of UI was an pm and an X. And that was like around like five or six years ago. And like model Federation happenings were like right now, so and the thing which people should be watching so it was released a couple of years ago, but it's mainstream. And this is like a great time to actually to jump on a train and to be an expert which will be in demand and to watch how like how your industry evolved. So enjoy the journey because well operations just starting. Yeah,

Dmitriy Shekhovtsov
I think another big one there is like with federate, so one Federation's had a good chance to mature came out in 2020. We've gotten a lot of feedback on it and contributing back or fixing some of these issues just isn't realistic to do inside Webpack because it'll take weeks to months. So you know, no, but Well, now that we kind of pulled this out of Webpack and made it a bit more, one easier to maintain across Webpack and RS pack now. But the other big thing is is cool now we actually own the code fully. We don't have to go through a foundation or through somewhere else to try and get any user request at it. And it's a lot lower risk to do but this also means that as we're busy bringing All this stuff out, if you want something, you can ask for it. And we will probably implement it. Somebody asked for, I don't know, there's two hooks I added because users asked for them. And I added them. And I'm like, Oh, this is actually great. And I ended up using them. So it's a really, really great opportunity for, hey, if you see this stuff, and you have certain challenges with it, we are in a much stronger place to be able to control the direction it goes. And again, we're trying to move it away from Bundler dependence, there's even a pull request open somewhere in here ESM support for the servers. So once we have that, I'll probably see well, can with the community, can we look at getting an import map binding as well. And then once we have that, it's essentially that the bundler is are optional extras that produce more efficient, more compatible artifacts, maybe with higher tier capabilities. But if you just want front end and you want something basic, you could do the native Federation approach, but you would still have lifecycle hooks to control it, I think, again, comes down to that is like, Whatever you do, you need something to mend scripts once they're there, and how they're going to come together. So yeah, if anybody does, you know, if you're looking at it, or if you find something that you'd like out of it and file an issue on our Git repo, and it's a lot easier for us to either go in and add this hook or add this capability, or we can kind of walk you through and show you how we would do it, or thanks to the new runtime plug in thing. A lot of things don't have to be implemented in our core, we can just write community extensions, and the community can control those, I believe, somewhere in the future, server side rendering and node support will just be a runtime plugin, it won't actually be a compiler plugin, it will just be something you add on as a runtime. So you know, just to give you an idea of how much you can do out of these API's, it's it's much less than Webpack plugin, and it's much more a library that is implemented in, you know, by a bundler for extra features. It's really, yeah, yeah.

Ryan Burgess
It's really cool to hear you all talk through that too, because it is like, it's something that, you know, has been around, it's still early, but it's been around long enough that it's been more mature. But also, there's so much more of that future working out, which is really cool to see. Well, let's dive into pics. In each episode, the front end happier podcast, we'd like to just share things that we found interesting share with all of our listeners, Zack, you want to start it off.

Zack Chapple
So something I found interesting. So this is a new venture to becoming a CEO of a startup. So having to learn a lot about VCs and investors and being a CEO because usually I'm not the CEO, usually Dimas the CEO, so I'm having to learn things. And a good a good first pick is is the book called The hard thing. The hard thing about hard things by Ben Horowitz that was recommended to me by one of our angel investors and he's like, You need to read this book so you can learn how to be CEO and deal with all this stuff. And and so that's been a good one. And then also I have a second. Sheila's eat. I don't know if you've ever had that. That's something I've been drinking that's been helping my focus and you know, shameless plug. Black Lotus Sheila's eat it's gonna be was dying of course. It's one of the things we don't drink it we use it on a fairly you could drink it too. So like is it just different uses depending on where you're from? And you know, it's a it's a read off a bunch of little double walled glass. Revkin so it's been good. Awesome.

Ryan Burgess
Zach, what do you have for us? Oh,

Dmitriy Shekhovtsov
I guess a couple Okay, so one pic, and it's not very code related, but that's the LG or no, not the LG the Samsung G nine UltraWide monitor 49 inch one I think that is it's definitely worth it. Definitely worth it. So I would totally recommend any of those. Anybody who needs to keep a lot of windows open and everything because it's definitely changed. I used to have to 27 inches, and it's definitely not the same experience as a 49 inch curve. So if you're looking at the screens a lot and you need real estate, I totally recommend an ultra wide Yeah, I didn't think I'd like it as much as I did, but definitely worked out. Other picks I'm definitely going to be biased on this. So here we go as as chapel like setting the little chat there, I would say RS PAC definitely or the family that comes from it. So RS PAC is what my infra team has been working on. And pretty much what we've done is we've taken Webpack and we wrote it in rust and so all the power of Webpack with none of the negatives around it speed and you know, the challenges that we kind of seen around getting new code out the door in their maintenance. So from Rs pack, there's been a really nice little family that's popped up. So if you hate Webpack and you like VT, then you should check out Rs build which is a It's basically like a VT style build tool, configure that instruments RS packs, if you don't like it and you'd like you want react plug in, you can just pop that on RS build, and you have like a kind of CLI very, very streamlined experience for working with it. It also supports Federation as well, which is nice. Then from there, we also have Rs press, which is pretty nice, which is duck generation, if you need static docks, or just static sites in general, it's all a rust based implementation. It's what all of our RS press are spilled all of the RS pack, they all use RS press to do all of our duck sites, you can kind of get a feel for what they look like and what it can generate. And then this pic I've had for a while, but it hasn't come up yet. But bundle analysis is a real pain. I'm sure everybody's felt that if you've ever used Webpack. What is it the Webpack bundle analyzer. It's real awesome. It's showing you very little useful information beyond the files are large, and you have problem. So I felt that as well. And usually like you know, I think status scope is the only thing that I found to be somewhat useful, but it's very, very difficult to use. But what was nice is, we are going to be releasing something called Build doctor, I think it'll be Rs doctor to go with our RS pack, build press kind of thing. But it'll work with Webpack as well. And it's essentially going to give you like a ton of information, how long your compilation took how long it takes to resolve everything, you get a what is the flame chart showing your build time where all the build went where the bottlenecks are in your application. I believe it also pulls out type definitions, you can also sell your type signatures shows you duplicates, but basically everything you'd want to know about static analysis is kind of wrapped up in this in this dev tool. So for anybody with a big build, I definitely would say as soon as that hits, totally worth checking out. And that should wait. I'm hoping this quarter. But those would be my main my main picks,

Ryan Burgess
I just have two picks. Totally unrelated to this topic. But hey, whatever, Jem and I just had a practical engineering management course that released on front end masters, I'm excited that it's finally out there. We recorded kind of at the end of the year last year. So it's cool to see it out there. It covers topics like you know, why become a manager, hiring, giving feedback, building a strong team, there's just a lot of information in there. So I'm excited to see for you know how people take it. And then from our last episode, I let a lot of people know that I quit my job and taking some time off. And so in that time, I've been finding a lot of time to fly, fly my drone and take a lot of cool footage. So I thought I'd highlight the drone that I've been using I had recently upgraded to the DJI mini four Pro, it's been an awesome drone to fly with. I'm a fan of the mini series for anyone wanting to get started too, because there's just it's light. It's small, but also you just don't have to deal with a lot of the regulations and things that come with some of the bigger drones. So highly recommend checking that one out if you're interested in flying any drones. Thank you. The three of you for joining us, Zack. Dima and Zach, thank you so much for joining us. You've shared some amazing insights in Module Federation and brought us up to speed on Zephyr where can people get in touch with you? Twitter, scripted alchemy,

Dmitriy Shekhovtsov
easiest way to find me?

Zack Chapple
Well Orkin for the last maybe 25 years? Find me anywhere just Google it. The crazy business guy on LinkedIn. Zack Chapple on link Zachary chapel on LinkedIn. Awesome.

Ryan Burgess
Well, thank you all for listening to our episode. As I said at the start of our episode, we are now on YouTube. So you can find us on there at @frontendhh. We're on Twitter at front of Nietzsche age and front end happy hour.com. Any last words?

Zack Chapple
Thank you for having us. Yeah, thank you for having us. Great. Thanks for common