Episode 23

full
Published on:

15th Nov 2022

S1 E23: It's nice to build for the future (Zack / @ScriptedAlchemy)

Zack Jackson joins the show to talk about his origin story, from not doing well in high school, to teaching himself programming and becoming a core contributor to one of the most essential front-end development tools available: Webpack, as well as being a co-creator of Webpack Module Federation.

We discuss the benefits of being involved in really technical work in open source, and the benefits it has on your day job. His passion for working on distributed architectures and how he accidentally built a self-healing server using Module Federation. We also discuss state management using Recoil and how that helps decouple your application logic from the state.

Discussed Links

Transcript
Eddie:

Welcome to episode 23 of the web joy podcast.

Eddie:

I'm your host Eddie in this podcast, we interview guests about their origin

Eddie:

story and what makes them excited and joyful to be part of the tech community.

Eddie:

I hope you enjoy today's episode.

Eddie:

It's nice to build for the future with Zach Jackson.

Eddie:

Awesome.

Eddie:

Well thank you for joining us today, Zach.

Eddie:

I really appreciate you making the time.

Zack:

Yeah, absolutely.

Zack:

Uh, thanks for having me.

Zack:

Typically, I like

Eddie:

to start out by just kind of having you introduce yourself, you

Eddie:

know, who are you, what do you do?

Eddie:

Where do you work, the

Zack:

basics.

Zack:

Yeah.

Zack:

I'm a principal engineer at Lululemon, based out in Seattle.

Zack:

Pretty much work on, you know, anything involving the web there.

Zack:

So from platform product features, what we're gonna do in the future, all of.

Zack:

What's

Eddie:

your kind of story, right?

Eddie:

How did you get involved in tech?

Eddie:

How did you end up as a principal at Lulu 11?

Eddie:

Yeah.

Eddie:

What's that journey look like for.

Zack:

I was always interested in computers and networking and stuff

Zack:

like that, and I ended up writing code, I think when I was about 13 or 14.

Zack:

Started writing software, didn't do very well in high school.

Zack:

Finally graduated and just went into software cuz that's what I knew.

Zack:

Yeah.

Zack:

You know, it kind of just snowballed from there, you know,

Zack:

no formal training or anything.

Zack:

Just, I dunno.

Zack:

If you google enough of it, know how to find answers, then you

Zack:

can get everything that you need.

Zack:

So that's more or less what I did.

Zack:

And then finally I kind of started to run out of, um, I dunno.

Zack:

I feel like if you're in like the front end space, at some point you

Zack:

start to feel like you've seen it all.

Zack:

And at that point it's either you kind of pivot into back end or into another

Zack:

language, or you go deeper into the stack.

Zack:

And so that's really what I started doing.

Zack:

The thing I picked up on, or the thing that really caught my interest

Zack:

was like compilers and architecture.

Zack:

And so most of everything that I pivoted over to was working on compilers,

Zack:

working on architecting these.

Zack:

After building several myself, I had seen you.

Zack:

What pretty much ends up happening to just about every application and I

Zack:

kind of wanted to move into the space of solving that industry wide instead

Zack:

of just kind of doing the same thing.

Zack:

And that's, yeah, that's kind of where I made a bit of a name for myself,

Zack:

started contributing to Webpac and um, that's ultimately how I ended

Zack:

up coming to principal engineer was just make something scale.

Zack:

And that's easier said than done.

Eddie:

That definitely will do it though, right?

Eddie:

Like if you're working on big enough scales, on big enough things, then yeah.

Eddie:

You end up in a pretty nice position,

Eddie:

. Zack: Yeah.

Eddie:

The one thing I also found, like I enjoy open source quite a bit and

Eddie:

especially working on say something like Webpac, The one nice thing I found of

Eddie:

it is usually the complexity there is.

Eddie:

I mean, it's the most complicated thing that I've worked on.

Eddie:

So anything that I do professionally is generally quite trivial in comparison.

Eddie:

So it does make kind of the professional side of things a lot easier to kind

Eddie:

of go through the the ladders, just because most companies don't need

Eddie:

something that complicated, but that awareness of something more complex.

Eddie:

Really does help bolster day to day what you would do.

Eddie:

No, that makes complete sense, cuz, Yeah, like if you're having to

Eddie:

operate at this level in the open source community and then your day job is kind

Eddie:

of at this level, like it's kind of relaxing to work on your day job because

Eddie:

you're really having to use a lot of mental energy on the open source stuff.

Zack:

Yeah.

Zack:

You know, I mean it's like how do we deal with, say, some state management, not how

Zack:

do we parse as s t and A compiler for.

Zack:

At scale and at speed.

Zack:

So different class of issue, but you know, there's a lot of tie overs that

Zack:

you can get, especially like around good API design, like if you think

Zack:

of platforms and things like that.

Zack:

Yeah.

Zack:

And then to kind of where, I don't know, at least for me, what I got

Zack:

into was, okay, well how much can I make the compiler do so that I don't

Zack:

have to say, write rappers or write abstractions or anything like that.

Zack:

Bake it all into the platform similar to what next has kind of done, you

Zack:

just use it and it kind of works.

Zack:

Try to extend that out to the business cases as well.

Zack:

So custom plugins for the, for Webpac alleviates a lot of the

Zack:

engineering challenges from day to day.

Eddie:

Yeah, no, that makes complete sense and definitely

Eddie:

Webpac is how I came to know you.

Eddie:

Um, you know, I was looking into what to do with these module things and ran

Eddie:

across your talk on Module Federation.

Eddie:

All that stuff and that's kinda how I found you on Twitter and then

Eddie:

thought, hey, you'd be a, a fun guest to have on the, the podcast.

Eddie:

So your open source work continues to kind of be your primary thing there, . Awesome.

Eddie:

Well, yeah.

Eddie:

What kind of keeps you excited and interested working as a

Zack:

software engineer?

Zack:

I would say I'm definitely a bit biased, but you know, I mostly work on this stuff

Zack:

all the time, so distributed architecture.

Zack:

That's probably what I'm most interested in and a lot of the things that I do

Zack:

revolve around around that, like in particular like, so there's Federation,

Zack:

which I had a part in building and I focus a lot of time on that.

Zack:

But things that kind of keep me excited inside of there is.

Zack:

Expanding what it can do.

Zack:

The biggest one is being able to do the server side, so it's not just a browser

Zack:

side tech, but the same kind of capability being able to say server side render

Zack:

something, or high density computing, where the way I always think of it is

Zack:

like what serverless was supposed to be.

Zack:

So instead of, you know, you upload a zip file to the Lambda and it's

Zack:

serverless, it's still your, your code is bound to compute primitive,

Zack:

and the only way to update that code is to tear down the compute primitive

Zack:

and bind new files to a different one.

Zack:

Or if I wanna say roll back, I need to have another lambda.

Zack:

To reroute traffic too.

Zack:

So what's been very interesting is getting rid of that and just saying,

Zack:

find a CPU on the internet and compute anything that I want it to.

Zack:

At any point, I can hit this, this Lambda, and it can be ssr.

Zack:

I can hit it again, it can be GraphQL or SSR can call itself

Zack:

and become a GraphQL endpoint.

Zack:

In the same kind of loop through not having all the files bound

Zack:

to the compute primitive.

Zack:

So that ability to, you know, just stream software into any machine and

Zack:

it become whatever you want, has been really interesting just to play with.

Zack:

But from a scale standpoint, it's also been really interesting to

Zack:

think about for disaster recovery.

Zack:

If this API isn't working or if something doesn't work, I could just catch

Zack:

it and say, Okay, stream a previous deployment of the one thing that didn't

Zack:

work, and then rerun that part of the.

Zack:

Without having to say, reroute it to another Lambda or anything like that.

Zack:

So that's what I found super interesting.

Zack:

Instead of having to deploy, say, a mountain of Lambdas, I can just put up

Zack:

one and I just have everything else on s3.

Zack:

And Webpac is just pulling down what I need as I need it, and because I have

Zack:

access to that run time and nothing's bound to the machine, if any error

Zack:

comes up or I need to roll back or do anything personalized, I can hot

Zack:

reload the production servers and just pull in pretty much any piece of

Zack:

code across the company that I need.

Eddie:

That's cool.

Eddie:

I remember seeing a tweet you did probably a couple weeks or a month or two ago

Eddie:

or something, but I don't remember what website it was, but one of the websites

Eddie:

you were running, like had like crashed or the, like, one of the servers had crashed

Eddie:

and like you hadn't even realized because it was like kind of auto recovered itself.

Eddie:

And that was, that was an interesting tweet.

Eddie:

I was like, Wait,

Zack:

what?

Zack:

Yeah, so that was like, I had planned to build something

Zack:

like more official for that.

Zack:

I haven't like gotten around to like making it an easy thing

Zack:

to do, but just how I had kind of designed the architecture.

Zack:

It hap like, it accidentally ended up self-healing.

Zack:

So when I would see an error come across, the only way I noticed something might

Zack:

be wrong is it took like an extra 200 milliseconds to respond and that was

Zack:

cuz the server would completely crash.

Zack:

The dependency tree would renegotiate mid-flight and then rerun it and

Zack:

then respond with the correct thing.

Zack:

It's very cool considering that would usually be a 500 error for it to just be

Zack:

an extra hundred milliseconds, and I still only had one Lambda ever deployed, so it

Zack:

was just one branch and it always worked.

Zack:

And that ability to try and make something that's extremely hard to knock off line is

Zack:

it's really cool just to see it in action.

Eddie:

Self-healing server.

Eddie:

What you're telling me is you basically built Skynet and it's

Eddie:

gonna destroy the world now, . Well,

Zack:

it's still, uh, and we need the, we need the machine learning portion of it,

Zack:

so you don't have to try catch everything.

Zack:

But I mean, , that's true.

Zack:

It would be very cool to have a Skynet type system.

Zack:

At least not the one that destroys the world, but from a it fixes itself

Zack:

kind of standpoint runs itself.

Zack:

Yeah.

Eddie:

Nice.

Eddie:

That's awesome.

Eddie:

One of the things that we do as we talk in these podcasts is kind of

Eddie:

talking about, hey, like what brings us joy in the tech industry and stuff.

Eddie:

And so just wanted to ask, what's something that brings

Eddie:

you joy that you'd like to talk?

Zack:

I would say so something new that I've, that I've started to dive into has

Zack:

been recoil and that has actually been quite refreshing compared to, I mean,

Zack:

I've mostly just kind of stuck with Redux cuz I kind of did what I need,

Zack:

but working in say, distributed systems.

Zack:

We start to get into this weird space of if any piece of software

Zack:

can change at any point in time without redeploying the host layer.

Zack:

How do you make it stay reliable?

Zack:

Usually, you know, if it's redux, you kind of hydrate the store up front.

Zack:

It's a monolith, so it's not gonna change out from under you.

Zack:

But if I have an inventory component and I can deploy that at any point in.

Zack:

And put it anywhere on an application.

Zack:

How do I ensure that it can always fetch inventory?

Zack:

So this idea of, okay, well I need it to fetch its own data.

Zack:

That's great until every component's fetching its own data.

Zack:

Now you've got your DDoS and your backend or something like that.

Zack:

So trying to figure out, okay, how can I say, whoever needs it first, get it.

Zack:

Everybody else reference it and trying to build something where I

Zack:

don't, there's no binding to the page.

Zack:

When you put multiple things on the page, they will work together without any

Zack:

like strict coupling and can communicate between each other without needing to

Zack:

go and say, alter the page and say, We'll wrap these two in context, or

Zack:

create a callback between A and B, but just, um, Some kind of atomic layer

Zack:

where I could just broadcast, Hey, this is gonna change and something

Zack:

else can respond to it without other parties having to be aware of it.

Zack:

And so that challenge was quite tricky until I kind of came across

Zack:

recoil and it seems to solve a lot of the concerns that I'd had about

Zack:

making something self-sustaining and making it efficient as well.

Zack:

So Recoils been a big relief for me in the past couple weeks.

Zack:

That's really

Eddie:

interesting.

Eddie:

I actually haven't heard of Recoil, um, hasn't come across.

Eddie:

Kind of timeline or anything yet.

Eddie:

So I was just looking it up cuz I'm like, Oh, this sounds new,

Eddie:

but that's looks pretty cool.

Zack:

The best way that, like, I'd never really heard of it

Zack:

until someone on my team was like, Hey, have you checked this out?

Zack:

And I'm like, Lemme go.

Zack:

Lemme go check it out.

Zack:

And the way they kind of described it to me was, it's kind of as if

Zack:

you were to take the React render and instead of html, it's state.

Zack:

And so it's got like the ding engine.

Zack:

It even uses the react internals for scheduling and stuff like that.

Zack:

So it's almost like having another render tree that just does JSON

Zack:

state for updating the application.

Zack:

Then you have your HTML tree, which is reacting.

Zack:

You have recoil, which is the same thing, but for state.

Zack:

So now only if I change this state down here, re render that subsection

Zack:

and don't, you know, repaint the whole application or rerun it.

Zack:

But it's really, really neat.

Zack:

I must admit it's, it's like if you were to make React for State,

Zack:

that's kind of what recoil is.

Zack:

There's a couple like other.

Zack:

Things that are similar.

Zack:

I think like you might have heard of Zest Stand or Joy Tie.

Zack:

Those are some other state libraries that have come out.

Zack:

I think

Eddie:

Joy Tie sounds familiar.

Eddie:

The first one

Zack:

didn't, but yeah.

Zack:

Yeah.

Zack:

Joy Tie's, uh, from developer Dehi have him on Twitter.

Zack:

He, he makes a couple really interesting things, but they all seem to be

Zack:

doing kind of like a similar concept.

Zack:

But yeah, recoil, joy ties us stand.

Zack:

Any of those, I think would kind of, A similar kind of need, but it is really

Zack:

nice when you're looking for something that's more efficient and more modular.

Zack:

We always are talking about trying to make things modular, but that only goes so far.

Zack:

And then as soon as you hit context, it's like, well, it's modular until I need a

Zack:

side effect from higher up in the tree.

Zack:

And you have to know, well, if I don't wrap in context, it's not gonna work.

Zack:

Mm-hmm.

Zack:

. So it'd be great to say, Well, all I have to do is wrap it

Zack:

and say like the recoil route.

Zack:

So put that in the app.

Zack:

Shell, everyone has.

Zack:

Put anything anywhere you want and it'll either get or create the data bindings

Zack:

that it needs, which is, um, a nice pattern for keeping things truly modular.

Eddie:

No, this sounds really interesting.

Eddie:

I'm definitely gonna have to dive into this more, um, when I have the

Eddie:

time because this looks, uh, looks pretty cool and looks really easy too.

Eddie:

Like, I mean, it's, it feels very natively.

Eddie:

React doesn't feel like anything's being bolted on.

Eddie:

I.

Eddie:

You literally replace use state with use recoil state, and like the API is

Eddie:

the exact same as a use state hook.

Eddie:

So that's sweet.

Zack:

The nice thing about it, it's, uh, suspense friendly.

Zack:

So you can put a promise as one of the, yes.

Zack:

Like say if I wanna go get price, that's an async method and it'll just return.

Zack:

The price statically, like if I cons log right under the hook, it's not a

Zack:

promise, it's the resolved promise.

Zack:

And there's a, We use something called service side effect, which is pretty

Zack:

much like suspense for React 17 or 16.

Zack:

It's a way to like say, okay, double render the app on the first render.

Zack:

Collect all these promises, take those side effects, load them in somewhere,

Zack:

await that set of side effects, come back, fill up context, and then

Zack:

actually let the real render happen.

Zack:

Bit of a hack, but it's really great cuz we could start developing say

Zack:

component level data fetching that's works on the server side while waiting

Zack:

for say next Gs to fully support it.

Zack:

Or you know, if you can't move to 18 yet you could build an

Zack:

application based on suspense pattern.

Zack:

And when you move to suspense, you just get rid of service side effect and replace

Zack:

it with like, use, fetch or whatever the, the normal suspendable hook would be.

Zack:

And so with recoil, you can either support it right out the box,

Zack:

or if not, there's two setters.

Zack:

One of them's like a suspendable setter, and another one will be the hook

Zack:

will immediately return the promise.

Zack:

And so what I usually do is I'll say, Cool, like, you know, get recoil state.

Zack:

I get back the async operation right below it.

Zack:

I have a use server side effect, and I just take from the state into the server

Zack:

side effect and return the recoil state.

Zack:

And now that will force the application to pause during a synchronous render, wait

Zack:

for all the data to fill out, and then it'll actually continue rendering the app.

Zack:

So I just have to remove one hook and then my whole application is back on suspense.

Zack:

But I can build that out ahead of time, which is really, really, That's huge

Eddie:

because so much is frustrating.

Eddie:

If you like, like you said, you're stuck in a certain version, say React

Eddie:

17 or whatever, but you're building something new and you wanna be able to

Eddie:

build, like with a new architecture.

Eddie:

I've run into that so many times on teams where it's like, well, we can't

Eddie:

move yet because we're in a big company.

Eddie:

We have all these dependencies, but instead, like we don't really wanna

Eddie:

build with the old pattern and then have to rewrite it in six months or a year

Eddie:

when we actually get to the new version.

Eddie:

That seems like a huge, a huge deal to be able to write the suspense pattern

Eddie:

in 17 and then just kind of make small updates to when you get to 18.

Zack:

If you were to say, take the two hooks and abstract it out,

Zack:

and compose a new hook that has.

Zack:

Use service side effect recoil state or something like that.

Zack:

And you just have that hook be cool, recoil state, and then right

Zack:

below it, service side effect.

Zack:

Then you could just pull that in and it automatically suspends it.

Zack:

So all you have to do is change your abstraction and say, well drop off the

Zack:

use suspense and change it from like use state to use suspendable effect or

Zack:

whatever it's called in, in recoil and that's the only change you would make.

Zack:

And automatically everything would work.

Zack:

But we've been doing component level data fetch.

Zack:

With this pattern for probably like a year now.

Zack:

So, you know, 18 just came out and it's still not fully supported next,

Zack:

but we've already got a good portion of the application built where the

Zack:

components fetch their own data and fulfill everything that they need to.

Zack:

So the only piece we really had to figure out was, well, how do

Zack:

we do efficient state management?

Zack:

So we're not hitting those APIs a lot, but the way I always look at it is,

Zack:

well, this is an inevitability anyway.

Zack:

If we have a way to just double end with the app, thanks to how

Zack:

React is and how memory management.

Zack:

Double rendering a server app.

Zack:

I mean it's like an extra, I think 20 milliseconds to do the final

Zack:

render cuz it's the first render.

Zack:

That's the slow one.

Zack:

It has to require everything, it has to do all of that.

Zack:

If I just go render to string again, it's like 10 to 20 milliseconds.

Zack:

So I'd much rather just say, Okay, let me make it 20 milliseconds slower.

Zack:

And I've enabled, you know, the next two and a half years or so of

Zack:

my application's life cycle a year ahead of when suspense is even gonna

Zack:

come out or when React 18 is even a.

Zack:

Back on React 16, we were building with that pattern.

Zack:

So by the time 18 comes out, it's just dropping shms.

Zack:

But it's nice to build for the future and not kind of be stuck with what you have

Zack:

right now, but be able to design and as long as it's still, it's just, you know,

Zack:

we always try to think of it is, it should happen to work today, but it's really

Zack:

designed for what's not yet available because when it is, you're already set.

Eddie:

I love that building for the future.

Eddie:

That's a great set of tools.

Eddie:

I'm gonna definitely include like links to all the different tools that

Eddie:

we talked about in the show notes.

Eddie:

So if any of these things stood out to you all, feel free

Eddie:

to check out the show notes.

Eddie:

Links are there.

Eddie:

You can click on 'em.

Eddie:

Check out whatever is interesting to you from that.

Eddie:

And yeah, I mean, before we wrap up here, Zach, as a community, we love to

Eddie:

support each other and we just wanted to see, is there anything you're involved

Eddie:

in or anything you've been working on that you'd like to just share with the

Eddie:

community that they might find helpful?

Zack:

Yeah, so I've been doing a couple things recently, some of

Zack:

these things like in various stages, but we just dropped a beta for

Zack:

remote type support for federation.

Zack:

So if I'm pulling in federated code that can be deployed at any time, everybody

Zack:

always asks, Well, what about the types?

Zack:

You know, I still have to npm install the types and you know, you don't

Zack:

know when the other deployment is gonna happen, so you don't really

Zack:

know when those types are gonna.

Zack:

So we wrote a plugin that will pretty much federate your types in.

Zack:

So as soon as you start a Webpack build it synchronizes the

Zack:

types with the deployed types.

Zack:

And now, you know, every time when you're in development, you always have the types

Zack:

that are currently in production for any of this federated code that's coming in.

Zack:

Another one that we are like, I'm pretty sure the type

Zack:

script plugin is like good now.

Zack:

So what we're starting to do is look at how can we apply federated unit.

Zack:

To do the same thing.

Zack:

One, I could do liability testing.

Zack:

So if you're gonna say, if checkout's gonna deploy a new add to cart,

Zack:

Capability during their deploy, they could pull in the product pages, unit

Zack:

tests and verify that when they do the deploy, because the product page uses

Zack:

that functionality, it's not gonna break the product page and vice versa.

Zack:

When the product page is about to deploy, it could pull in the

Zack:

unit tests from checkout and confirm added bag still works.

Zack:

On top of that, it would finally give us support to not have to do end-to-end

Zack:

tests, to test federated code.

Zack:

But now cuz it's all bs, so it's gonna see, I don't know what this import.

Zack:

You know, it's some non-existent import, so this process should allow it.

Zack:

So if you have federated modules inside of your react tree, it will actually load

Zack:

the code similar to how it would on the browser, on the server, can load the code.

Zack:

So you can actually perform unit tests against other federated modules just to

Zack:

confirm things don't go wrong, which is, it's a big quality of life improvement.

Zack:

Cause I think that's been one of the concerns.

Zack:

This is, it's really great that we can pull software in at runtime, but

Zack:

it does make it trickier to test and you have to lean on end to end test.

Zack:

So we're trying to make it just adapters so that it'll just work

Zack:

the same way you would expect it to.

Zack:

We've got our type script plugin out now.

Zack:

One of the commercial ones that I've got out is service side

Zack:

rendering support for N js.

Zack:

So if anybody is interested in that, it is available.

Zack:

It's currently a release candidate, so probably a bug or two still.

Zack:

It's been really nice to say, you know, you don't have to say, use like next

Zack:

JS zones or something like that, but I could just say, Here's a Lambda.

Zack:

Deploy all the pages and the whole app works as a single page app,

Zack:

even though it's maybe 15 next JS independent deployments, but no page

Zack:

refresh at all service side renders.

Zack:

It's just as efficient as a single monolithic application in

Zack:

terms of script tags get loaded.

Zack:

Everything gets loaded the way you would expect it to.

Zack:

And then, yeah, one that will keep on the radar is we're working on

Zack:

service discovery for the front.

Zack:

So with all these distributed things, it would be great if, or

Zack:

in micro fronts in general, how do I know who's using what and where?

Zack:

And that's a huge problem just to discover, well, what's the dependency of,

Zack:

say the homepage who, Or if I go to Megan Ave, where's Megan Ave is being consumed.

Zack:

That's really hard to trace across multiple repos.

Zack:

So we're finalizing a product called Medusa, which will come with a plug.

Zack:

That will pretty much upload the webpac graph of every individual build.

Zack:

And then we can parse that all and we can figure out, here's

Zack:

all the dependencies you're using across your entire organization.

Zack:

Here's who's using what from where, and we'll add on the ability to

Zack:

say, control the versions of it.

Zack:

So you could do an instant rollback by just changing.

Zack:

The Webpac runtime at runtime through this, so you wouldn't have to redeploy

Zack:

to say roll something back or to pin to a certain version or roll forward.

Zack:

You just log in, change it from the dropdown, and it instantly changes

Zack:

how the Webpac Graph operates, which is, Which is pretty neat.

Eddie:

Wow, that seems like magic.

Eddie:

You know what I mean?

Eddie:

Like click, move.

Eddie:

The module that's being pulled in.

Eddie:

That's live.

Eddie:

That's

Zack:

crazy.

Zack:

The demo that I put up on YouTube was a little while ago, but the one I put up

Zack:

on YouTube was I have a design system and it's built of five independent

Zack:

repos, and each repo is gonna use button version one is red, version

Zack:

two is green, version three is blue.

Zack:

And I could go to the.

Zack:

Like the search bar and I could say, Okay, use the previous

Zack:

version of the design system and I reload the page and it's now red.

Zack:

So I could have like four or five different ver colors of the

Zack:

button on the page each from their own design system without having

Zack:

to npm install or do anything.

Zack:

And the meantime to update was two seconds.

Zack:

So within two seconds you can update Wow.

Zack:

Any part of your dependency tree, just with a click of a

Zack:

button, which is really great.

Zack:

If we think about big enterprise things where resilience and

Zack:

recovery is, is extra, I.

Zack:

So definitely is

Eddie:

useful.

Eddie:

That's really awesome.

Eddie:

So if someone you know is interested in all this stuff, is there

Eddie:

somewhere they can go to kind of find out more, follow along?

Eddie:

Is there a website or Twitter account?

Eddie:

What?

Eddie:

What would be best for them to

Zack:

do?

Zack:

Scripted alchemy.

Zack:

My Twitter account, that would be probably where like the stream

Zack:

of consciousness flows out of.

Zack:

I also own the module federation org on GitHub, so just

Zack:

github.com/module-federation.

Zack:

That's where all, you know, the public things are that, that we put out there.

Zack:

And there will be a website to come along for something like

Zack:

Medusa or things like that.

Zack:

But in general, if, if you're looking for anything, I would say the module

Zack:

federation org is a good place to start.

Zack:

We have a big repo called Module Federation examples.

Zack:

On that read, I usually put there like, you know, here's some examples.

Zack:

Here are the companies that are using this type of tech, and I will go and update

Zack:

it to say, here's all the like products and things that we own, or Here's all

Zack:

the things we built for the ecosystem, just so it's easier to find what's

Eddie:

out there.

Eddie:

Awesome.

Eddie:

No, that sounds perfect.

Eddie:

So if you all are interested in some of the more module federation stuff,

Eddie:

especially like I'm a big type script person so you know, if you've been kind

Eddie:

of holding out cuz of types or different things like that, follow Zach on Twitter.

Eddie:

Go check out the GitHub page repo.

Eddie:

And uh, thank you for coming on Zach.

Eddie:

It's been great chatting and uh, hope you have a great day.

Zack:

Yeah, you too.

Zack:

Thanks for having me.

Zack:

.

Zack:

It's nice to build for the future with Zach Jackson.

Zack:

You can find out more about Zach on his Twitter.

Zack:

At scripted alchemy.

Zack:

You can find links to everything we talked about in this episode, as well as a link

Zack:

to Zack's Twitter in the show notes.

Zack:

And if you enjoyed this episode, help others discover it as

Zack:

Why don't you give us a shout out on Twitter, maybe tag a friend or coworker,

Zack:

if you think they'd enjoy And don't forget to follow us on Twitter, to stay

Zack:

up to date at web joy, F M thank you for listening and have a great day.

Show artwork for WebJoy

About the Podcast

WebJoy
Find your happy place
The WebJoy podcast is an inclusive community centered on celebrating the diverse origins, skills, and experiences that make up the tech industry.

Talking with guests about their origin stories, what they love about working in their roles, and what they find joy in keeps this an upbeat and rather lighthearted podcast.

We approach the world with optimism and hope, while recognizing the flaws and challenges within our own industry and the world at large. We believe that if we work together, we can all find our happy place.

About your host

Profile picture for Eddie Hinkle

Eddie Hinkle

Eddie's mission is to bring joy and empathy to the tech industry. He does this through engineering leadership, mentoring and podcasting. Eddie currently works as an Engineering Manager at Glassdoor, Mentors on ADPList and hosts the WebJoy podcast.