Welcome to episode 23 of the web joy podcast. I'm your host Eddie in this podcast, we interview guests about their origin story and what makes them excited and joyful to be part of the tech community. I hope you enjoy today's episode. It's nice to build for the future with Zach Jackson. Awesome. Well thank you for joining us today, Zach. I really appreciate you making the time.
Yeah, absolutely. Uh, thanks for having me. Typically, I like
to start out by just kind of having you introduce yourself, you know, who are you, what do you do? Where do you work, the
basics. Yeah. I'm a principal engineer at Lululemon, based out in Seattle. Pretty much work on, you know, anything involving the web there. So from platform product features, what we're gonna do in the future, all of. What's
your kind of story, right? How did you get involved in tech? How did you end up as a principal at Lulu 11? Yeah. What's that journey look like for.
I was always interested in computers and networking and stuff like that, and I ended up writing code, I think when I was about 13 or 14. Started writing software, didn't do very well in high school. Finally graduated and just went into software cuz that's what I knew. Yeah. You know, it kind of just snowballed from there, you know, no formal training or anything. Just, I dunno. If you google enough of it, know how to find answers, then you can get everything that you need.
So that's more or less what I did. And then finally I kind of started to run out of, um, I dunno. I feel like if you're in like the front end space, at some point you start to feel like you've seen it all. And at that point it's either you kind of pivot into back end or into another language, or you go deeper into the stack. And so that's really what I started doing. The thing I picked up on, or the thing that really caught my interest was like compilers and architecture.
And so most of everything that I pivoted over to was working on compilers, working on architecting these. After building several myself, I had seen you. What pretty much ends up happening to just about every application and I kind of wanted to move into the space of solving that industry wide instead of just kind of doing the same thing.
And that's, yeah, that's kind of where I made a bit of a name for myself, started contributing to Webpac and um, that's ultimately how I ended up coming to principal engineer was just make something scale. And that's easier said than done.
That definitely will do it though, right? Like if you're working on big enough scales, on big enough things, then yeah. You end up in a pretty nice position, . Zack: Yeah. The one thing I also found, like I enjoy open source quite a bit and especially working on say something like Webpac, The one nice thing I found of it is usually the complexity there is. I mean, it's the most complicated thing that I've worked on. So anything that I do professionally is generally quite trivial in comparison.
So it does make kind of the professional side of things a lot easier to kind of go through the the ladders, just because most companies don't need something that complicated, but that awareness of something more complex. Really does help bolster day to day what you would do.
No, that makes complete sense, cuz, Yeah, like if you're having to operate at this level in the open source community and then your day job is kind of at this level, like it's kind of relaxing to work on your day job because you're really having to use a lot of mental energy on the open source stuff.
Yeah. You know, I mean it's like how do we deal with, say, some state management, not how do we parse as s t and A compiler for. At scale and at speed. So different class of issue, but you know, there's a lot of tie overs that you can get, especially like around good API design, like if you think of platforms and things like that.
Yeah. And then to kind of where, I don't know, at least for me, what I got into was, okay, well how much can I make the compiler do so that I don't have to say, write rappers or write abstractions or anything like that. Bake it all into the platform similar to what next has kind of done, you just use it and it kind of works. Try to extend that out to the business cases as well. So custom plugins for the, for Webpac alleviates a lot of the engineering challenges from day to day.
Yeah, no, that makes complete sense and definitely Webpac is how I came to know you. Um, you know, I was looking into what to do with these module things and ran across your talk on Module Federation. All that stuff and that's kinda how I found you on Twitter and then thought, hey, you'd be a, a fun guest to have on the, the podcast. So your open source work continues to kind of be your primary thing there, . Awesome. Well, yeah. What kind of keeps you excited and interested working as a
software engineer? I would say I'm definitely a bit biased, but you know, I mostly work on this stuff all the time, so distributed architecture. That's probably what I'm most interested in and a lot of the things that I do revolve around around that, like in particular like, so there's Federation, which I had a part in building and I focus a lot of time on that. But things that kind of keep me excited inside of there is. Expanding what it can do.
The biggest one is being able to do the server side, so it's not just a browser side tech, but the same kind of capability being able to say server side render something, or high density computing, where the way I always think of it is like what serverless was supposed to be.
So instead of, you know, you upload a zip file to the Lambda and it's serverless, it's still your, your code is bound to compute primitive, and the only way to update that code is to tear down the compute primitive and bind new files to a different one. Or if I wanna say roll back, I need to have another lambda. To reroute traffic too. So what's been very interesting is getting rid of that and just saying, find a CPU on the internet and compute anything that I want it to.
At any point, I can hit this, this Lambda, and it can be ssr. I can hit it again, it can be GraphQL or SSR can call itself and become a GraphQL endpoint. In the same kind of loop through not having all the files bound to the compute primitive. So that ability to, you know, just stream software into any machine and it become whatever you want, has been really interesting just to play with. But from a scale standpoint, it's also been really interesting to think about for disaster recovery.
If this API isn't working or if something doesn't work, I could just catch it and say, Okay, stream a previous deployment of the one thing that didn't work, and then rerun that part of the. Without having to say, reroute it to another Lambda or anything like that. So that's what I found super interesting. Instead of having to deploy, say, a mountain of Lambdas, I can just put up one and I just have everything else on s3.
And Webpac is just pulling down what I need as I need it, and because I have access to that run time and nothing's bound to the machine, if any error comes up or I need to roll back or do anything personalized, I can hot reload the production servers and just pull in pretty much any piece of code across the company that I need.
That's cool. I remember seeing a tweet you did probably a couple weeks or a month or two ago or something, but I don't remember what website it was, but one of the websites you were running, like had like crashed or the, like, one of the servers had crashed and like you hadn't even realized because it was like kind of auto recovered itself. And that was, that was an interesting tweet. I was like, Wait,
what? Yeah, so that was like, I had planned to build something like more official for that. I haven't like gotten around to like making it an easy thing to do, but just how I had kind of designed the architecture. It hap like, it accidentally ended up self-healing. So when I would see an error come across, the only way I noticed something might be wrong is it took like an extra 200 milliseconds to respond and that was cuz the server would completely crash.
The dependency tree would renegotiate mid-flight and then rerun it and then respond with the correct thing. It's very cool considering that would usually be a 500 error for it to just be an extra hundred milliseconds, and I still only had one Lambda ever deployed, so it was just one branch and it always worked. And that ability to try and make something that's extremely hard to knock off line is it's really cool just to see it in action.
Self-healing server. What you're telling me is you basically built Skynet and it's gonna destroy the world now, . Well,
it's still, uh, and we need the, we need the machine learning portion of it, so you don't have to try catch everything. But I mean, , that's true. It would be very cool to have a Skynet type system. At least not the one that destroys the world, but from a it fixes itself kind of standpoint runs itself. Yeah.
Nice. That's awesome. One of the things that we do as we talk in these podcasts is kind of talking about, hey, like what brings us joy in the tech industry and stuff. And so just wanted to ask, what's something that brings you joy that you'd like to talk?
I would say so something new that I've, that I've started to dive into has been recoil and that has actually been quite refreshing compared to, I mean, I've mostly just kind of stuck with Redux cuz I kind of did what I need, but working in say, distributed systems. We start to get into this weird space of if any piece of software can change at any point in time without redeploying the host layer. How do you make it stay reliable?
Usually, you know, if it's redux, you kind of hydrate the store up front. It's a monolith, so it's not gonna change out from under you. But if I have an inventory component and I can deploy that at any point in. And put it anywhere on an application. How do I ensure that it can always fetch inventory? So this idea of, okay, well I need it to fetch its own data. That's great until every component's fetching its own data. Now you've got your DDoS and your backend or something like that.
So trying to figure out, okay, how can I say, whoever needs it first, get it. Everybody else reference it and trying to build something where I don't, there's no binding to the page.
When you put multiple things on the page, they will work together without any like strict coupling and can communicate between each other without needing to go and say, alter the page and say, We'll wrap these two in context, or create a callback between A and B, but just, um, Some kind of atomic layer where I could just broadcast, Hey, this is gonna change and something else can respond to it without other parties having to be aware of it.
And so that challenge was quite tricky until I kind of came across recoil and it seems to solve a lot of the concerns that I'd had about making something self-sustaining and making it efficient as well. So Recoils been a big relief for me in the past couple weeks. That's really
interesting. I actually haven't heard of Recoil, um, hasn't come across. Kind of timeline or anything yet. So I was just looking it up cuz I'm like, Oh, this sounds new, but that's looks pretty cool.
The best way that, like, I'd never really heard of it until someone on my team was like, Hey, have you checked this out? And I'm like, Lemme go. Lemme go check it out. And the way they kind of described it to me was, it's kind of as if you were to take the React render and instead of html, it's state. And so it's got like the ding engine. It even uses the react internals for scheduling and stuff like that.
So it's almost like having another render tree that just does JSON state for updating the application. Then you have your HTML tree, which is reacting. You have recoil, which is the same thing, but for state. So now only if I change this state down here, re render that subsection and don't, you know, repaint the whole application or rerun it. But it's really, really neat. I must admit it's, it's like if you were to make React for State, that's kind of what recoil is. There's a couple like other.
Things that are similar. I think like you might have heard of Zest Stand or Joy Tie. Those are some other state libraries that have come out. I think
Joy Tie sounds familiar. The first one
didn't, but yeah. Yeah. Joy Tie's, uh, from developer Dehi have him on Twitter. He, he makes a couple really interesting things, but they all seem to be doing kind of like a similar concept. But yeah, recoil, joy ties us stand. Any of those, I think would kind of, A similar kind of need, but it is really nice when you're looking for something that's more efficient and more modular. We always are talking about trying to make things modular, but that only goes so far.
And then as soon as you hit context, it's like, well, it's modular until I need a side effect from higher up in the tree. And you have to know, well, if I don't wrap in context, it's not gonna work. Mm-hmm. . So it'd be great to say, Well, all I have to do is wrap it and say like the recoil route. So put that in the app. Shell, everyone has.
Put anything anywhere you want and it'll either get or create the data bindings that it needs, which is, um, a nice pattern for keeping things truly modular.
No, this sounds really interesting. I'm definitely gonna have to dive into this more, um, when I have the time because this looks, uh, looks pretty cool and looks really easy too. Like, I mean, it's, it feels very natively. React doesn't feel like anything's being bolted on. I. You literally replace use state with use recoil state, and like the API is the exact same as a use state hook. So that's sweet.
The nice thing about it, it's, uh, suspense friendly. So you can put a promise as one of the, yes. Like say if I wanna go get price, that's an async method and it'll just return. The price statically, like if I cons log right under the hook, it's not a promise, it's the resolved promise. And there's a, We use something called service side effect, which is pretty much like suspense for React 17 or 16. It's a way to like say, okay, double render the app on the first render.
Collect all these promises, take those side effects, load them in somewhere, await that set of side effects, come back, fill up context, and then actually let the real render happen. Bit of a hack, but it's really great cuz we could start developing say component level data fetching that's works on the server side while waiting for say next Gs to fully support it. Or you know, if you can't move to 18 yet you could build an application based on suspense pattern.
And when you move to suspense, you just get rid of service side effect and replace it with like, use, fetch or whatever the, the normal suspendable hook would be. And so with recoil, you can either support it right out the box, or if not, there's two setters. One of them's like a suspendable setter, and another one will be the hook will immediately return the promise. And so what I usually do is I'll say, Cool, like, you know, get recoil state. I get back the async operation right below it.
I have a use server side effect, and I just take from the state into the server side effect and return the recoil state. And now that will force the application to pause during a synchronous render, wait for all the data to fill out, and then it'll actually continue rendering the app. So I just have to remove one hook and then my whole application is back on suspense. But I can build that out ahead of time, which is really, really, That's huge
because so much is frustrating. If you like, like you said, you're stuck in a certain version, say React 17 or whatever, but you're building something new and you wanna be able to build, like with a new architecture. I've run into that so many times on teams where it's like, well, we can't move yet because we're in a big company.
We have all these dependencies, but instead, like we don't really wanna build with the old pattern and then have to rewrite it in six months or a year when we actually get to the new version. That seems like a huge, a huge deal to be able to write the suspense pattern in 17 and then just kind of make small updates to when you get to 18.
If you were to say, take the two hooks and abstract it out, and compose a new hook that has. Use service side effect recoil state or something like that. And you just have that hook be cool, recoil state, and then right below it, service side effect. Then you could just pull that in and it automatically suspends it.
So all you have to do is change your abstraction and say, well drop off the use suspense and change it from like use state to use suspendable effect or whatever it's called in, in recoil and that's the only change you would make. And automatically everything would work. But we've been doing component level data fetch. With this pattern for probably like a year now.
So, you know, 18 just came out and it's still not fully supported next, but we've already got a good portion of the application built where the components fetch their own data and fulfill everything that they need to. So the only piece we really had to figure out was, well, how do we do efficient state management? So we're not hitting those APIs a lot, but the way I always look at it is, well, this is an inevitability anyway.
If we have a way to just double end with the app, thanks to how React is and how memory management. Double rendering a server app. I mean it's like an extra, I think 20 milliseconds to do the final render cuz it's the first render. That's the slow one. It has to require everything, it has to do all of that. If I just go render to string again, it's like 10 to 20 milliseconds. So I'd much rather just say, Okay, let me make it 20 milliseconds slower.
And I've enabled, you know, the next two and a half years or so of my application's life cycle a year ahead of when suspense is even gonna come out or when React 18 is even a. Back on React 16, we were building with that pattern. So by the time 18 comes out, it's just dropping shms.
But it's nice to build for the future and not kind of be stuck with what you have right now, but be able to design and as long as it's still, it's just, you know, we always try to think of it is, it should happen to work today, but it's really designed for what's not yet available because when it is, you're already set.
I love that building for the future. That's a great set of tools. I'm gonna definitely include like links to all the different tools that we talked about in the show notes. So if any of these things stood out to you all, feel free to check out the show notes. Links are there. You can click on 'em. Check out whatever is interesting to you from that.
And yeah, I mean, before we wrap up here, Zach, as a community, we love to support each other and we just wanted to see, is there anything you're involved in or anything you've been working on that you'd like to just share with the community that they might find helpful?
Yeah, so I've been doing a couple things recently, some of these things like in various stages, but we just dropped a beta for remote type support for federation. So if I'm pulling in federated code that can be deployed at any time, everybody always asks, Well, what about the types? You know, I still have to npm install the types and you know, you don't know when the other deployment is gonna happen, so you don't really know when those types are gonna.
So we wrote a plugin that will pretty much federate your types in. So as soon as you start a Webpack build it synchronizes the types with the deployed types. And now, you know, every time when you're in development, you always have the types that are currently in production for any of this federated code that's coming in. Another one that we are like, I'm pretty sure the type script plugin is like good now. So what we're starting to do is look at how can we apply federated unit.
To do the same thing. One, I could do liability testing. So if you're gonna say, if checkout's gonna deploy a new add to cart, Capability during their deploy, they could pull in the product pages, unit tests and verify that when they do the deploy, because the product page uses that functionality, it's not gonna break the product page and vice versa. When the product page is about to deploy, it could pull in the unit tests from checkout and confirm added bag still works.
On top of that, it would finally give us support to not have to do end-to-end tests, to test federated code. But now cuz it's all bs, so it's gonna see, I don't know what this import. You know, it's some non-existent import, so this process should allow it. So if you have federated modules inside of your react tree, it will actually load the code similar to how it would on the browser, on the server, can load the code.
So you can actually perform unit tests against other federated modules just to confirm things don't go wrong, which is, it's a big quality of life improvement. Cause I think that's been one of the concerns. This is, it's really great that we can pull software in at runtime, but it does make it trickier to test and you have to lean on end to end test. So we're trying to make it just adapters so that it'll just work the same way you would expect it to. We've got our type script plugin out now.
One of the commercial ones that I've got out is service side rendering support for N js. So if anybody is interested in that, it is available. It's currently a release candidate, so probably a bug or two still. It's been really nice to say, you know, you don't have to say, use like next JS zones or something like that, but I could just say, Here's a Lambda.
Deploy all the pages and the whole app works as a single page app, even though it's maybe 15 next JS independent deployments, but no page refresh at all service side renders. It's just as efficient as a single monolithic application in terms of script tags get loaded. Everything gets loaded the way you would expect it to. And then, yeah, one that will keep on the radar is we're working on service discovery for the front.
So with all these distributed things, it would be great if, or in micro fronts in general, how do I know who's using what and where? And that's a huge problem just to discover, well, what's the dependency of, say the homepage who, Or if I go to Megan Ave, where's Megan Ave is being consumed. That's really hard to trace across multiple repos. So we're finalizing a product called Medusa, which will come with a plug. That will pretty much upload the webpac graph of every individual build.
And then we can parse that all and we can figure out, here's all the dependencies you're using across your entire organization. Here's who's using what from where, and we'll add on the ability to say, control the versions of it. So you could do an instant rollback by just changing. The Webpac runtime at runtime through this, so you wouldn't have to redeploy to say roll something back or to pin to a certain version or roll forward.
You just log in, change it from the dropdown, and it instantly changes how the Webpac Graph operates, which is, Which is pretty neat.
Wow, that seems like magic. You know what I mean? Like click, move. The module that's being pulled in. That's live. That's
crazy. The demo that I put up on YouTube was a little while ago, but the one I put up on YouTube was I have a design system and it's built of five independent repos, and each repo is gonna use button version one is red, version two is green, version three is blue. And I could go to the. Like the search bar and I could say, Okay, use the previous version of the design system and I reload the page and it's now red.
So I could have like four or five different ver colors of the button on the page each from their own design system without having to npm install or do anything. And the meantime to update was two seconds. So within two seconds you can update Wow. Any part of your dependency tree, just with a click of a button, which is really great. If we think about big enterprise things where resilience and recovery is, is extra, I. So definitely is
useful. That's really awesome. So if someone you know is interested in all this stuff, is there somewhere they can go to kind of find out more, follow along? Is there a website or Twitter account? What? What would be best for them to
do? Scripted alchemy. My Twitter account, that would be probably where like the stream of consciousness flows out of. I also own the module federation org on GitHub, so just github.com/module-federation. That's where all, you know, the public things are that, that we put out there. And there will be a website to come along for something like Medusa or things like that. But in general, if, if you're looking for anything, I would say the module federation org is a good place to start.
We have a big repo called Module Federation examples. On that read, I usually put there like, you know, here's some examples. Here are the companies that are using this type of tech, and I will go and update it to say, here's all the like products and things that we own, or Here's all the things we built for the ecosystem, just so it's easier to find what's
out there. Awesome. No, that sounds perfect. So if you all are interested in some of the more module federation stuff, especially like I'm a big type script person so you know, if you've been kind of holding out cuz of types or different things like that, follow Zach on Twitter. Go check out the GitHub page repo. And uh, thank you for coming on Zach. It's been great chatting and uh, hope you have a great day.
Yeah, you too. Thanks for having me. . Eddie: Thanks for joining us for episode 23. It's nice to build for the future with Zach Jackson. You can find out more about Zach on his Twitter. At scripted alchemy. You can find links to everything we talked about in this episode, as well as a link to Zack's Twitter in the show notes.
And if you enjoyed this episode, help others discover it as Why don't you give us a shout out on Twitter, maybe tag a friend or coworker, if you think they'd enjoy And don't forget to follow us on Twitter, to stay up to date at web joy, F M thank you for listening and have a great day.