Module Federation Microfrontends with ByteDance’s Zack Jackson

[@omomer3506]

This is that kind of episode which you need to listen to more than once

[@StingSting844]

It's unbelievable how these guys consistently post about exactly what I need at work or what I'm interested in. I'm making a microfrontend architecture at work using module federation and here is a great interview! But to be honest, he doesn't dumb it down enough for the rest of us.

[@WesBos]

👀 we know

[@isuperman1113n]

You can use astro alongside module federation as the host for your micro frontends

[@jeremytenjo]

Zack is at the top of the app development food chain. Great pod!

[@koen5777]

Awesome to see Zack on my favorite podcast! 🙌

[@tom.watkins]

Awesome I suggested you get Zack on only a few weeks ago and here he is 😂 nice!

[@harisonfekadu]

I wish I understood what he is saying.

[@MrHopp24]

Dynamic linking at runtime instead of static building -> deployment. I think…

[@hello_world_104]

Ya literally not one thing was English. I think this guys target audience is one person, Wesbos

[@zackjackson9674]

Dynamically import parts from other builds. And how do you make that stable? Like npm package publishing and installation, but without needing to run `npm install` each time a consuming app needs to update a package. That's a similar analogy.

[@RyanForT3hWin]

It’s a good ego check for me to hear real developers talk about their work.

[@jameswilliams7183]

I think the hosts also do tbh

[@timfish]

The best quote is "it solves a problem I hope I never have" 😆

[@zackjackson9674]

Facts 😂 Kent is a legend

[@kissu_io]

Love how this goes to the exact opposite of DHH's no build approach. 👌🏻

[@kamikaz1k]

Great episode. Would be cool if he live demo'd a few of the things he mentioned.

[@brucej9451]

It would be great to have CJ demonstrate federation in Vite along with some explanation of a few key scenarios.

[@owennicol83]

27:06 How does module federation compare to Edge Side Includes (ESI)? We use ESI to share code, but it’s more than just JS modules, it’s discreet web apps like a whole header/footer. Is MF always going to be just JS? How do we share CSS/HTML with this approach?

[@jameswilliams7183]

There has to be a better way than this. One that A: Is less fragile and B: Less convoluted. This whole video reminded me of this sketch: kzbin.info/www/bejne/r2myn6KugNSnhrM. Although to be honest I understood basically nothing.

[@thenglong]

masterpiece

[@deatho0ne587]

At a fortune 500. The reason we did it was due to QA thinking they had to test every single piece of our APP. So instead of taking one day to test, they said they wanted three weeks plus to test everything. Even though DEVs would only take 2 hours (dev time + deploy time) to change a function, QA would still take three times. To be fair I thought it was a bit excessive. The issue with this is they would find things in stuff not touched in a bit. Meaning we would go to the last version of QA that had not been deployed in about a month and see the issues QA was bringing up was still there. Now to be fair a lot of the problems were issues but it was issues they were not catching the first time.

[@simonhartley9158]

Where I worked we'd create new tickets for these additional finds and then they'd just sit in the backlog never to be addressed.

[@StingSting844]

This is an organisational issue. Principal engineers are to blame for letting this culture set in. Push for automation and atomic deloys

[@deatho0ne587]

@simonhartley9158 again they were issues and generally easy to solve. So we normally put the Jr devs on it since they were hard to replicate most of the time, which is why they were not found the first time

[@simonhartley9158]

@StingSting844 What principal engineer? The customer prioritised what was worked on and there was no QA capacity for extra. The automation was a mess handed off between various different QAs who never got it running clean.

[@deatho0ne587]

@StingSting844 even though I agree in some context. I can not say QA testers are bad overall, it was really just a few that wanted to do end to end testing every time. If nothing else it is nice to learn how to set-up a MFE project with multiple repo's, since I can now have more than just a demo of it under my belt.

[@ShivamMishra-mn6cs]

i was not able to find think he mention in last "chatgpt meets e2e testing"

[@v1r47]

Love the smoke :D

[@taufiqdev]

:O interested on how Lynx will be doing their styling. Similar to rn’s stylesheet or tailwind rather?

[@ngideo]

3:11 Somebody once said (I think it was Gergely Orosz) its an inside joke in the industry that every company has their own "ReactNative". Wild to see it might be true

[@drumforhim]

11:25 been there, done that!!! 😂

[@JLarky]

16:24 "there's no backend server" I figured

[@phii7u]

At 20:30 my brain left. I don’t know any of the things he just mentioned

[@MrJfergs]

What is Hermes? This is very convoluted it seems like only .5 % of people would need this level of complexity though.

[@zackjackson9674]

Hermes is the JS engine inside React Native. We wrote the Lynx engine due to business KPIs. Regarding federation, we have seen that the majority of Fortune 500 companies need it, compared to the alternative of npm packages. At runtime, distribution was an order of magnitude less complex at scale. It also increased product output by an average of 300%. Federation has been key to the companies' success, as they can build and ship apps faster than most others. The problem is that, at scale, there are few solutions. If you don't have scale issues, then you probably don't need it.

[@charbelsarkis3567]

is he holding an iqos? 31:10

[@ob34915]

I am confused

[@griffadev]

I'd just quit

[@_parassolanki]

This kind of things gives me imposter syndrome

[@dovh49]

It seems like this would be simpler with HTMX, Web Components, and eventing to interact with each other. Also, any packages you're bringing in it would be easier to make sure they are all brought in with version numbers attached. This seems really complex. But I've never needed anything quite this complex. So, I could be completely wrong.

[@zackjackson9674]

It's pretty simple. The mechanics under the hood are complex. HTMX and WC didn't work for us. Federation works in backend and native apps, too. We needed a universal solution for code sharing and distribution.

[@zackjackson9674]

Eventing also is very limiting. Most users need to share complex memory references. Not strings. Like send a component into another module, or share state. Serialization based communication is often too restrictive for apps that need good performance. Also eventing usually is over global bus. Easy to make collisions

[@seannewell397]

@@zackjackson9674 sharing state seems like a mess to me; do you already have a blog / interview / example of how to decide when it is worth the organizational connection to share state? The hard thing I'm going to face soon is that it is trivial to do this in our system, just make an API on top of a zustand store, for example (can be even simpler imo), but then some unknown number of subscribers depend on your state in ways you cannot foresee. But also, if you just don't allow it in the FE, then some tangled mess of data interactions likely happens in the BE. We find it's usually worth asking penetrating questions, because sometimes the product and domain architecture itself can be redrawn to be clearer with less connections.

[@dovh49]

@@zackjackson9674 Thanks for the replies. Yes, it definitely seems complex and a problem I hope I never have 🙂.