Thank you so much for keeping the MFE and module federation stuff alive. It feels like everyone else, including the React team, is laser focused on the SSR story only.
Tell me about it. And on top of it we've got people going around spreading FUD about SPAs, how they are "bad for performance". No reasons given. Just "bad for performance". Uh huh. Ok.
It's for that very reason that I really dislike what's happening in the React + Vercel space. They're solving "problems" that don't really push UX forward. In fact, many people would argue that we're essentially recreating php at this point. I guess this is what happens with marketing-driven-development. Simultaneously, the industry has basically standardized on React/Next so you it seems obligatory to stay up-to-date with this nonsense. It's disheartening.
@@iriel492ki Having done my time in the PHP salt mines I can say that I don't want to go back to that. I like the state -> html model, a lot. But now there are lots of ways to do that; Vue, Svelte, Solid, Angular, etc. I'm not a super fan of what's going on with React either. They are solving problems that front-line developers don't have. The things I see junior React devs struggle with are things like state management. Fix that, React team. Give us some React state primitives that aren't footguns. And the last time I checked, wasn't Facebook (cough, Meta) mostly a SPA? I haven't been on it in... almost a decade now, so maybe it has changed a lot, but I don't recall FB having a big interest in SSR.
@@iriel492ki just because they are solving a "problem" you don't have doesn't necessarily mean they aren't solving actual problems. Although I don't necessarily agree with everything React team is doing, usually when they release a feature it does push the industry forward and ends up being inspiration for others.
You made micro-frontends unbelievably easy in your previous tutorial where you used webpack. After moving onto Vite, this is exactly what I have been looking for! Thanks a heap Jack!
Great video, glad my colleague recommended it! We are actually building a similar system in my company. We use React, TS, Vite and the MF plugin - 5 apps, separate repos, their own pipelines, 5 dockers with nginx, kubernetes, etc, hosted on Azure. Our modules are page level apps with their own routers, and we don't share state other than some cookies. As for common stuff, we share components, utilities and typescript types using an NPM package and a private registry. Still ironing out some details, like auth in modules in local development or css sharing, but overall it seems like a solid solution!
This plugin is great, I have been using them for a while now. I ended up writing my own Vite configuration generator to abstract away some of the pain points with it, like the need of referencing the remote base URLs for every remotes and such.
Fantastic stuff! One really awesome thing you did in this demo, but didn't explicitly call out: You did NOT install Jotai in the host application! When you imported the federated store in the host, Jotai just came along with it, which is so cool.
Loved the video! Would also love to watch (and build together) a tutorial of a more complete micro front end using this vite plugin. Thanks for the amazing job Jack!
Great explanation, also to answers the questions that you need to build and preview, that's important to know from the start, Could you share something about how to handle with tailwind classes, I'm having issues with that, cannot get the styles in the host app 🙏
This reminds me of "back in the day," around 9:00 with the federation plugin having this `exposes` and `shared` keys. Before we had Vite and Webpack, we had require.js. Which was the Webpack of its time. The problem with require.js was that it became insanely unmanageable as the dependency list grew. It got to a point where we'd have to leave comments above some of the keys to denote _what_ they did and why. If a dependency was removed, then everything broke. Seems like this is going back to old patterns that couldn't scale.
Another great video about MF and MFE! You're awesome 💯! I have been watching so many of your videos about this topic recently, some of them are more than a year old but when I tried out the codes, they're still working surprisingly well! Thank you so much for making such a high-quality content, so fun to watch and easy to follow! Just wondering if you could do another round of handling runtime error using the latest techniques available today. Thanks again Jack.
Maybe? Kinda depends on how Module Federation videos fair on the channel. All these videos are time consuming to produce, so I need to make sure there is an audience that will benefit from them.
Great video, I would have liked to see you include some routing on both the host and remote. I think that is a problem with not being able to include the router in the remote applications.
One thing I’ve noticed with Module Federation and s3 is 1. Using cloudfront caching can be a pain, need to invalidate quite a bit and interconnected shared components can get confusing 2. Lots to maintain and setup in Cloudfront when using many services, it can get confusing especially with the ugly cloudfront urls. That said I do really like Module Federation 🙌🏻
You can solve this by creating custom cloud-front behaviour, you can add a policy for cache disabled targeting only the entry file then all the other files are safe since they will be generated with an unique hash.
Great video (as always). For me, personally, whenever Typescript support is gone or becomes hard, unless the "pros" section is a HUGE list compared to the cons, I'm like "I'll pass for now"
It's not really gone, you can still use Typescript with Module Federation, you just have to create a definitions package which describes the contract of your remotes. You use it in remotes to make sure you follow the contract, and you use it in hosts to correctly consume your remotes. It is a bit tedious though, because you have to manually type your definitions, but it's the same as if it was a REST API call
@@phoenix-tt It's def not the same, with MF things can easily break, imagine props change. The host needs to be updated. This should only be used if you need to embed a application inside another application that are isolated from the host, and doesn't need any prop, then I think it's good fit. As soon as you use it as any other component then any change in the remote - will break in the host.
I was following along and laughing at the subtle humor up until the webpack interop. The way you identified the source of the issue and fixed it was amazing to say the least. I would like to understand the internals of webpack & the general bundling ecosystem. The word "module" is basically foreign to me on a deeper level. Are there any books/resources doing a deep dive into this (the deeper the better!). Great vid Jack
Thanks for the video! Not a big fan of MFEs, seems to me like it's adding more dynamic boundaries when the majority of workplace problems are caused by misalignment between teams already. IMO we need more typing not less. I feel like this will introduce the same kind of tribalism as BE microservices
Hi Jack! Great content. This video is stimulate my team to make a architect decision on new project. Could you please help me understand the challenges about management host and remote shared dependencies? Imagine multiple teams working on multiple remotes apps and a multiple commons dependencies.
Hi! Thanks for the video. I'm trying to use vite app as a host and webpack app as a remote but there is a cors error, can you help me how fix this error?
Thanks a lot for the video! I have a question: is it possible to expose an entire remote app so that it can be loaded directly into the parent app? I haven't been able to get this to work yet, even though it was possible using Webpack's Module Federation. Any advice would be appreciated!
I was really excited to see this video because I was hoping that you could finally use MF between running dev servers. The fact that you had to redeploy the remote (rather than just having a dev server auto update it with the perfect of Vite) was determined to make this plugin a non-starter for an org I was working for last year. 😔
Agree. The inability to serve remotes with dev server is a deal breaker to me. I'm evaluating using @module-federation/vite instead, which works with dev server. It doesn't propagate hot reloading from the remote to the host and we need to refresh, but this is better than rebuilding on each change.
Thank you @jherr for this great tutorial! I would like to hear your insights regarding the sharing state between micro-frontends, as it seems to contradict the principle of separated entities, which should be its most vital selling point over monolith-repo... The way I understand it, each entity should make its own data call to the server or (for example in case of user credentials/sessions) from cookies, but not from a shared store or state...
Yes, you should share as little state as possible between MFEs. Ideally just the user JWT, and perhaps something like the cart if you are doing e-Commerce.
I'm using vue typescript but when building and preview the host I have an error message Cannot find module 'remoteApp/BlueButton' or its corresponding type declarations
Excellent video, sir. I prefer the port numbers to be provided via the vite.config.js from server: {...viteConfig, { port: 5001 }, preview: { port: 5001 } }
when I config follow your desc, i see the hot reload is disabled. When I change code in remote app, the host app can't watch and change. Can you help me to make the host app can read the remote, please.
The module federation stuff is great BUT problematic in terms of web workers. I tried both webpack and vite and when You have to consume federated module inside of web worker, then it gets problematic, or to be more precise - right now it is simply broken. Hope they will deal with it someday.
Thanks for a great video! I've been testing Vite/MFE with a large remote-app with multiple dependencies, and it seems like this is not the best fit. The Vite-plugin is not able to handle old libs that are not configured exactly the way they're supposed to be. With Webpack, on the other hand, there are workarounds. Looking forward to be able to move away from Webpack when the technology has matured!
Good Explanation. If possible, can you do one video on module federation with Nuxt 3, this will be really helpful if you can make it. I have explored on the Google, but didnt find examples related to Nuxt3 module federation with shared libraries like PrimeVue
Sadly we had to drop vite and migrate back to webpack since vite-plugin-federation does not recommended to mixing Vite and Webpack in React projects, which is the case in our project :( Hopefully they can get this sorted soon
In real application should we share the whole app component of each remote app, and download it lazy? And how can I implement nested routing in this case?
The project I'm on at work is using MFEs but the people who made that choice hadn't used it before so it's been a learning process for everyone. Not only that but these MFEs are being hosted through microservices...and surprise surprise the store sharing and lib sharing has become a headache to manage. Doing vertical slices in a mono repo would've be much simpler but they wanted to do microservices in individual repos when they hadn't done microservices before either....ugh... Resume architecting is what we call it...gotta get those buzz words in these days...
Hey, nice video! That's cool that you can start mixing Vite & Webpack applications, but it raises a few more questions: 1/ how would you make your host load both Webpack & Vite remotes (ideally, in an agnostic way) ? 2/ could the host use Vite and load a remote Webpack application? Thanks again for your videos on MFE, they are really becoming one of the main sources of knowledge on the topic !
1. You mean without that default hack? Dunno. I mean, you could wrap it in a function that looks at the module export and sees if there is a default and uses that. 2. I'm not sure I understand what you are asking, but sharing a whole application sounds unwise at best.
@@jherr 2/ I mean, if you take your example at 20:00 and do it the other way around: you implement and expose a button from a remote Webpack app and try to import it in a Vite app (the host)... Can it work?
@@gfox1984 I haven't tried it, and I invite you to, it would be simple, but I would be surprised if it didn't work. There is really nothing magically going on here. The React components are the same functions, code wise, whether they are imported directly, or through a mono-repo, or through Module Federation. If you can get access to the component function, and you've done so without bringing in another instance of React, then everything should work just fine.
@@jherr I have to say I got cold feet looking at the note on their repo: github.com/originjs/vite-plugin-federation#integration-with-webpack "It is not recommended to mix Vite and Webpack in React projects, as there is no guarantee that Vite/Rollup and Webpack will generate the same chunk when packaging commonjs, which may cause problems with shared." But I'll try to give it a go
Thank you for sharing! any ideas how to make HMR work? So that any change in the remote component will be immediately reflected in the host. I've seen your comment about setting up --watch mode, however in our specific use case, the remotes can get pretty large, with thousands of components making the watch cycle a very bad dev experience.
awesome video thank you very much for the content. really great how up to date technologies you are testing and presenting! sadly the part with having module federation as a host and a vite as remote doesn't work on my end. could you link the github repo as comment?
For deploying assets, it seems better to mention common CDN solutions rather than an object storage. Netlify / AWS CloudFront / Cloudflare etc. S3 is OK to play with an simpler tho, so might be easier to get started, but always deploy for real to a CDN
Agreed. Anything other than serving it out of your SSR server. Serving it out of the server is a particularly bad idea because NextJS used to (not sure if it does it still) serve whatever it has for JS assets regardless of their checksum, which made non CDN rolling deploys very ... exciting.
Hi Jack, i'm a big fan of your micro-fes videos, thanks a lot. Lately I got an Astro project to consume using Vite a Vue micro-fe exposed via Webpack with module federation. I am currently struggling to make it work with SSR. Just wondering if you could provide some help with micro-fes and making them run in SSR mode (ie with Astro). Best regards!
I would check with Fred and the Astro team on that, but my guess is that they probably don't think that's an awesome idea. Honestly, MFEs in SSR never really made much sense to me since I discourage using MFEs for mission critical page elements. So doing MFEs primarily on the client is ok with me. But hey, I don't know your use case, so if you require SSR then yeah, I'd reach out to that team.
Can you give an example of where you would need to use runtime sharing? Because It seems like the cons stack is way more significant than the actual value we are getting here. Also, if reusable components are shared across multiple repos shouldn't we extract them to entirely different Micro Frontend(library works here). Great video!
Hey jack, thanks for the enlightning video, If you wanna go the opposite, I mean, to consume a module from webpack to vite, what would be the config in the vite project? If you have a reference it will be awesome, thanks.
Another great walkthrough. I've been coding along and I've initialised react ts project instead. It threw me a ts error. In order to correctly import the button I had to add a type declaration for it in my host project. I guess its because we load projects/modules dynamically at runtime and typescript doesnt know what are the types. Thanks a lot for the input and insights youre giving!
I liked your video, nice explanation, easy to follow, I would like to move one step forward, how to handle the errors like when remote app is down or not built, could you please post a video or comment on this, it will be really helpful, I am working on vite vue module federation
Great tutorial! I have a question, lets say, if I expose a Micro-Frontend using Module Federation with Vite, can I consume it somehow from a Next.js application?
Hi sir, I'm creating a project with vite with vue3, i m using vite plugin SSR package, and implement the microfrontend with vite plugin federation, but error is occured, my error is file, data, node only allows with esm, not support http, how to solve this, please give the solution
Error when evaluating SSR module /component: failed to import "localhost:3002/dist/client/assets/remoteEntry.js" |- Error: Only URLs with a scheme in: file, data, and node are supported by the default ESM loader. Received protocol 'http:' at throwIfUnsupportedURLScheme (node:internal/modules/esm/load:239:11)
Awesome video! About tree shaking, it seems like module federation struggles there too. Since we need to manually set up shared packages in each micro-app's bundling config as well as the host, it can cause duplicate packages downloaded by the client, right?
A good technique is to bring the package.json data into the vite.config and then just up Object.keys on the dependencies object to set up the shared array programatically. That way it's always kept in sync. Tree shaking is clearly an issue. Not really sure what can be done about that. The module will include all the code in the exported module and anything local it depends on. And I wouldn't expect it to tree shake because it's impossible to know what will be called and what won't.
@Allysson dos Santos It sounds like in your case you should go with build-time dependencies. Because a given runtime library can't know which of its exports will be used, so it has to retain them all.
Well, now this is something useful. Thanks for sharing Jack! Quick non-related question: how did you manage to put the address bar on top of Arc browser?
Loved this one !! I learned MFEs from your vdos only. Can we do a host - vite + react 18 + its own route and client - webpack + react 16 + its own route. Would be great if there is 1 vdo focused in different route strategies used in MFEs . Please guide if you have any info on this topic 🙂
Thanks for watching! Maybe this is just me but I don't think the MFEs as routes thing is a good idea. But if a lot of folks want me to cover that I certainly can. Technically speaking it's not that challenging.
I've spent some time with this trying to set up a remote app (vite) in a project where I don't control the host app (webpack). I got "SyntaxError: Cannot use "import.meta' outside a module (at remoteEntry.js:8:30)". At 9:50, line 9 in this video. Do you have any suggestions on how to get around that? I guess it's esm related, but I can't seem to figure out a way to solve it from the remote app.
I really love your videos. I am just starting to learn about MFE. I would just like to ask if i can have different versions of react on host and app? lets say i have a legacy code that we can't upgrade the react version to be the same version as my MFE would that be an issue?
I see some projects using Module Federation within a Monorepo. Why would you do this if the monorepo (Turborepo) can manage the micro-frontend archictecture?
There are lots of options around hardening. You can use ErrorBoundaries. You can do some fallback behavior to a lazily loaded import of the build-time module. But all that requires a lot of work to implement, test, and stay consistent with it. So it's a big commitment.
@@jherr and if there are some breaking changes in one of the libs some kind of versioning might be required. It seems like it becomes very complicated rather quickly. Sharing CSS seems like a pain too, as I understand it it has to be bundled with JS. Shared lob versions need to be synced between teams.
@@radulaski Yep, totally agree. That's why I put a section in this on pros/cons because there are a lot of cons. It's great to have access to this functionality, but it comes with a lot of risk and complexity. In a lot of my previous videos I didn't cover the downsides and folks came away thinking that Module Federation was way easier than using a monorepo. When in reality, it starts off being easier to share a component, but to actually get it hardened to production level, it's way harder than with a monorepo.
so, @jherr please let me so vite only provides build time sharing not runtime sharing? I tried loading the remotes dynamically in runtime, when I stops the remote the shell goes down!. I can't run both in dev mode, how I do with Webpack.
When using proper SolidJS functionality, I got it to build, but for some reason, it's not exposing the remoteEntry.js file at all (or even creating it in the /dist folder).
This specific plugin seems to be broken for React right now. React isn't correctly shared as a singleton causing deeper parts of the federated component tree to not detect it. In other words, if the module you are exporting uses a React hook at any level below the top level; it will crash. Meaning a lot more complex apps will simply break if shared through this.
I have a wild idea I wanted to get some feedback on. We have several "core" apps that we currently use as stand alone MFEs. I've been trying to convince our team to switch our core apps to a monorepo. With that in mind we allow customers to create third party apps to support their own needs. If we converted our core apps to a monorepo, we would still want to use module federation for stand alone MFE's. Could i combine this approach with a turborepo, the turborepo being the "remote" or atleast 1 app in the turborepo would be the remote? Is that over engineering?
single-spa uses in browser module resolution so effectively also doing run time module resolution. What are the benefits of this approach over that? It feels like single-spa has already done what module federation is trying to do now. But please feel free to correct me if my assumption here is wrong.
Single SPA is focused specifically on UI component sharing, and it is _fantastic_ at that. It also helps a lot with inter-framework development. So putting a Vue component on a React page is not a problem with Single-SPA. What Single-SPA doesn't do well is more low level sharing, if what you want to share is just logic, they don't have a model for that AFAIK. FWIW, I see the two approaches as complimentary. Last time I checked Single-SPA could leverage Module Federation as a code transport method. Also I think the import method for Module Federation is way cleaner than SystemJS.
Hello, Can you make react advance tutorial like optimization, memo and best practices, will really appreciate it, me and even who are looking the to level up their skills with concepts and practices
What do you think about using something like xState for shared state? I liked it as it was very easy to share the context and the various actions in one neat bundle while the component just implements the visuals and triggers for those actions and state.
Hi Jack! Great content thank you so much. From personal experience in a large project where you have many MFEs, some are "legacy" and using webpack 5 (including the host UI), there are some compatibility issues when introducing new UIs written in vite and MF plugin for vite. Is this something you're familiar with?
@@omriterem6448 I showed in the video that Vite MF can load Webpack MF. It's actually all dynamic to start, it's just that the loader is doing a little auto-magic when you do an import to load the module dynamically automatically. And so you should be able to do a dynamic module load. If you want to know how I recommend looking at the demo code provided by the Vite plugin folks or in Zack's demo project.
Hey Jack, I don't remember if I made this question in another video. I am using Vite and its module federation plugin. All works fine but when I try to run vitest as test runner I get an error trying to load the remote url, how I can mock that url and tell to my test that ignore the components from remote app used in the host application?
Anyone tried Vite based module federation with Remix??? I cannot get assetUrl exposed, and “shared” is not allowing react and react-dom to be externalized
Nice! How do you share the user session to the mfe? Like a user profile and a shopping cart. User profile needs a session so does shopping cart. Can we do two-way-mfe ?
You could share the whole session object with an atom, but I'm not sure I would do that. I would create some atoms that pull out the specific data that the MFEs need so that an auth provider could change later.
I like the tab management stuff, the embedded popup window, and the popout video in Arc as compared to Chrome. TBH, I don't use Safari enough to have a good opinion on it. I know some folks who have switched to Safari and love it, there is also the Orion browser, which folks are raving about. There is just too much good stuff out there!
![[#2024MAMA] ROSÉ (로제), Bruno Mars - APT. | Mnet 241122 방송](http://i.ytimg.com/vi/dgGqD28J6aQ/mqdefault.jpg)
Thank you so much for keeping the MFE and module federation stuff alive. It feels like everyone else, including the React team, is laser focused on the SSR story only.
Tell me about it. And on top of it we've got people going around spreading FUD about SPAs, how they are "bad for performance". No reasons given. Just "bad for performance". Uh huh. Ok.
It's for that very reason that I really dislike what's happening in the React + Vercel space. They're solving "problems" that don't really push UX forward. In fact, many people would argue that we're essentially recreating php at this point. I guess this is what happens with marketing-driven-development.
Simultaneously, the industry has basically standardized on React/Next so you it seems obligatory to stay up-to-date with this nonsense. It's disheartening.
@@iriel492ki Having done my time in the PHP salt mines I can say that I don't want to go back to that. I like the state -> html model, a lot. But now there are lots of ways to do that; Vue, Svelte, Solid, Angular, etc.
I'm not a super fan of what's going on with React either. They are solving problems that front-line developers don't have. The things I see junior React devs struggle with are things like state management. Fix that, React team. Give us some React state primitives that aren't footguns.
And the last time I checked, wasn't Facebook (cough, Meta) mostly a SPA? I haven't been on it in... almost a decade now, so maybe it has changed a lot, but I don't recall FB having a big interest in SSR.
@@jherr I couldn't have said it better myself. I wish I could thumbs up this to the moon.
@@iriel492ki just because they are solving a "problem" you don't have doesn't necessarily mean they aren't solving actual problems. Although I don't necessarily agree with everything React team is doing, usually when they release a feature it does push the industry forward and ends up being inspiration for others.
You made micro-frontends unbelievably easy in your previous tutorial where you used webpack. After moving onto Vite, this is exactly what I have been looking for! Thanks a heap Jack!
Great video, glad my colleague recommended it! We are actually building a similar system in my company. We use React, TS, Vite and the MF plugin - 5 apps, separate repos, their own pipelines, 5 dockers with nginx, kubernetes, etc, hosted on Azure. Our modules are page level apps with their own routers, and we don't share state other than some cookies. As for common stuff, we share components, utilities and typescript types using an NPM package and a private registry. Still ironing out some details, like auth in modules in local development or css sharing, but overall it seems like a solid solution!
Did you have issues with the latest version? Shared dependencies are not singleton
Thank you for the video. Big fan of the Vite Federation plugin, i hope it will soon support, dynamic remotes, in similar way we have it in Webpack.
Why why...When I research something, you already posted those explanations and tutorials. Really Helpful! thanx
This plugin is great, I have been using them for a while now. I ended up writing my own Vite configuration generator to abstract away some of the pain points with it, like the need of referencing the remote base URLs for every remotes and such.
I heard vite couldn't make module federation so I've gave up on this idea. this is amazing!
I can listen to this man all day. Thank you so much
This was awsome tutorial Jack. Explained from very low level and how to rectify the issues.
I was looking for this kind of video for so long. worth watching every second.
Huge thanks for your great content Jack. Everytime when I am curious about something and you will make a video about that.
Fantastic stuff! One really awesome thing you did in this demo, but didn't explicitly call out: You did NOT install Jotai in the host application! When you imported the federated store in the host, Jotai just came along with it, which is so cool.
Yeah, it goes along with the code that consumes it as library export from the remote. Super clean.
Learned new things. Very sneaky webpack config, appreciate your effort !
Loved the video! Would also love to watch (and build together) a tutorial of a more complete micro front end using this vite plugin. Thanks for the amazing job Jack!
Module federation is a big reason we are still on webpack on some projects.
Great video and very fun. Would be super useful to actually see that whole S3 static store concept you referenced.
Great explanation, also to answers the questions that you need to build and preview, that's important to know from the start, Could you share something about how to handle with tailwind classes, I'm having issues with that, cannot get the styles in the host app 🙏
This reminds me of "back in the day," around 9:00 with the federation plugin having this `exposes` and `shared` keys. Before we had Vite and Webpack, we had require.js. Which was the Webpack of its time. The problem with require.js was that it became insanely unmanageable as the dependency list grew. It got to a point where we'd have to leave comments above some of the keys to denote _what_ they did and why. If a dependency was removed, then everything broke. Seems like this is going back to old patterns that couldn't scale.
Another great video about MF and MFE! You're awesome 💯! I have been watching so many of your videos about this topic recently, some of them are more than a year old but when I tried out the codes, they're still working surprisingly well! Thank you so much for making such a high-quality content, so fun to watch and easy to follow! Just wondering if you could do another round of handling runtime error using the latest techniques available today. Thanks again Jack.
Maybe? Kinda depends on how Module Federation videos fair on the channel. All these videos are time consuming to produce, so I need to make sure there is an audience that will benefit from them.
Great video, I would have liked to see you include some routing on both the host and remote. I think that is a problem with not being able to include the router in the remote applications.
One thing I’ve noticed with Module Federation and s3 is 1. Using cloudfront caching can be a pain, need to invalidate quite a bit and interconnected shared components can get confusing 2. Lots to maintain and setup in Cloudfront when using many services, it can get confusing especially with the ugly cloudfront urls. That said I do really like Module Federation 🙌🏻
You can solve this by creating custom cloud-front behaviour, you can add a policy for cache disabled targeting only the entry file then all the other files are safe since they will be generated with an unique hash.
It's been 2 years, wow 🤯. Really excited about module federation, again 😀. Thanks for really awesome video.
Yeah, it's kind of funny to compare the style of this video to the style of the Module Federation videos from a year (or more) ago.
Great video (as always). For me, personally, whenever Typescript support is gone or becomes hard, unless the "pros" section is a HUGE list compared to the cons, I'm like "I'll pass for now"
It's not really gone, you can still use Typescript with Module Federation, you just have to create a definitions package which describes the contract of your remotes. You use it in remotes to make sure you follow the contract, and you use it in hosts to correctly consume your remotes.
It is a bit tedious though, because you have to manually type your definitions, but it's the same as if it was a REST API call
@@phoenix-tt Good points, thank you!
@@phoenix-tt It's def not the same, with MF things can easily break, imagine props change. The host needs to be updated. This should only be used if you need to embed a application inside another application that are isolated from the host, and doesn't need any prop, then I think it's good fit. As soon as you use it as any other component then any change in the remote - will break in the host.
🤯Next level stuff right here.
I was following along and laughing at the subtle humor up until the webpack interop. The way you identified the source of the issue and fixed it was amazing to say the least. I would like to understand the internals of webpack & the general bundling ecosystem. The word "module" is basically foreign to me on a deeper level. Are there any books/resources doing a deep dive into this (the deeper the better!). Great vid Jack
You and me both. Honestly the whole multiple module standards in the ecosystem is a huge mess that makes me want to get more into Deno.
Thanks for the video! Not a big fan of MFEs, seems to me like it's adding more dynamic boundaries when the majority of workplace problems are caused by misalignment between teams already. IMO we need more typing not less. I feel like this will introduce the same kind of tribalism as BE microservices
TS & vite HMR support are the things that hold back developers to use this approach
It`s a nice and easy way to use micro front-ends! But, how works in production? I`m facing some issues with CORS using vite-plugin-federation :/
Hi Jack! Great content.
This video is stimulate my team to make a architect decision on new project.
Could you please help me understand the challenges about management host and remote shared dependencies?
Imagine multiple teams working on multiple remotes apps and a multiple commons dependencies.
Hi! Thanks for the video. I'm trying to use vite app as a host and webpack app as a remote but there is a cors error, can you help me how fix this error?
Thanks a lot for the video! I have a question: is it possible to expose an entire remote app so that it can be loaded directly into the parent app? I haven't been able to get this to work yet, even though it was possible using Webpack's Module Federation. Any advice would be appreciated!
I was really excited to see this video because I was hoping that you could finally use MF between running dev servers. The fact that you had to redeploy the remote (rather than just having a dev server auto update it with the perfect of Vite) was determined to make this plugin a non-starter for an org I was working for last year. 😔
Agree. The inability to serve remotes with dev server is a deal breaker to me. I'm evaluating using @module-federation/vite instead, which works with dev server. It doesn't propagate hot reloading from the remote to the host and we need to refresh, but this is better than rebuilding on each change.
Thank you @jherr for this great tutorial!
I would like to hear your insights regarding the sharing state between micro-frontends, as it seems to contradict the principle of separated entities, which should be its most vital selling point over monolith-repo...
The way I understand it, each entity should make its own data call to the server or (for example in case of user credentials/sessions) from cookies, but not from a shared store or state...
Yes, you should share as little state as possible between MFEs. Ideally just the user JWT, and perhaps something like the cart if you are doing e-Commerce.
I'm using vue typescript but when building and preview the host I have an error message
Cannot find module 'remoteApp/BlueButton' or its corresponding type declarations
I wonder how MFEs will evolve with stuff like Astro around
man this is insanec. thank you
Excellent video, sir. I prefer the port numbers to be provided via the vite.config.js from server: {...viteConfig, { port: 5001 }, preview: { port: 5001 } }
This project is worth Trying. every bit of it
when I config follow your desc, i see the hot reload is disabled. When I change code in remote app, the host app can't watch and change. Can you help me to make the host app can read the remote, please.
Excelent video, top level information! Jack, is there any way to pass props to the remoteApp component?
The module federation stuff is great BUT problematic in terms of web workers. I tried both webpack and vite and when You have to consume federated module inside of web worker, then it gets problematic, or to be more precise - right now it is simply broken. Hope they will deal with it someday.
Thanks for a great video! I've been testing Vite/MFE with a large remote-app with multiple dependencies, and it seems like this is not the best fit. The Vite-plugin is not able to handle old libs that are not configured exactly the way they're supposed to be. With Webpack, on the other hand, there are workarounds. Looking forward to be able to move away from Webpack when the technology has matured!
From what I hear from Evan You Vite is going to put full first class support for Vite into the framework. So here is hoping for improvement.
Good Explanation. If possible, can you do one video on module federation with Nuxt 3, this will be really helpful if you can make it. I have explored on the Google, but didnt find examples related to Nuxt3 module federation with shared libraries like PrimeVue
Sadly we had to drop vite and migrate back to webpack since vite-plugin-federation does not recommended to mixing Vite and Webpack in React projects, which is the case in our project :( Hopefully they can get this sorted soon
In real application should we share the whole app component of each remote app, and download it lazy?
And how can I implement nested routing in this case?
So now I am wondering, how do you unit-test your frontends when your components no longer exist in build time, but only in runtime?
The project I'm on at work is using MFEs but the people who made that choice hadn't used it before so it's been a learning process for everyone. Not only that but these MFEs are being hosted through microservices...and surprise surprise the store sharing and lib sharing has become a headache to manage.
Doing vertical slices in a mono repo would've be much simpler but they wanted to do microservices in individual repos when they hadn't done microservices before either....ugh...
Resume architecting is what we call it...gotta get those buzz words in these days...
"RET"s - Resume Enhancement Technologies
keep goin' loving the vids
Great video Jack! Thanks for sharing 👏🏻
Next is figuring out how to make these work in production builds. Localhost ports just won't work in that case. Nice tutorial.
You need to look at environment variables and change the URLs to the deployed locations during production build.
Hey, nice video! That's cool that you can start mixing Vite & Webpack applications, but it raises a few more questions:
1/ how would you make your host load both Webpack & Vite remotes (ideally, in an agnostic way) ?
2/ could the host use Vite and load a remote Webpack application?
Thanks again for your videos on MFE, they are really becoming one of the main sources of knowledge on the topic !
1. You mean without that default hack? Dunno. I mean, you could wrap it in a function that looks at the module export and sees if there is a default and uses that.
2. I'm not sure I understand what you are asking, but sharing a whole application sounds unwise at best.
@@jherr 2/ I mean, if you take your example at 20:00 and do it the other way around: you implement and expose a button from a remote Webpack app and try to import it in a Vite app (the host)... Can it work?
@@gfox1984 I haven't tried it, and I invite you to, it would be simple, but I would be surprised if it didn't work. There is really nothing magically going on here. The React components are the same functions, code wise, whether they are imported directly, or through a mono-repo, or through Module Federation. If you can get access to the component function, and you've done so without bringing in another instance of React, then everything should work just fine.
@@jherr I have to say I got cold feet looking at the note on their repo: github.com/originjs/vite-plugin-federation#integration-with-webpack
"It is not recommended to mix Vite and Webpack in React projects, as there is no guarantee that Vite/Rollup and Webpack will generate the same chunk when packaging commonjs, which may cause problems with shared."
But I'll try to give it a go
Great vid, but please hide Arc's sidebar, the video will look so much better without it.
Awesome video thanks!
Thank you for sharing! any ideas how to make HMR work? So that any change in the remote component will be immediately reflected in the host. I've seen your comment about setting up --watch mode, however in our specific use case, the remotes can get pretty large, with thousands of components making the watch cycle a very bad dev experience.
awesome video thank you very much for the content. really great how up to date technologies you are testing and presenting!
sadly the part with having module federation as a host and a vite as remote doesn't work on my end. could you link the github repo as comment?
GitHub code link is in the description.
For deploying assets, it seems better to mention common CDN solutions rather than an object storage. Netlify / AWS CloudFront / Cloudflare etc. S3 is OK to play with an simpler tho, so might be easier to get started, but always deploy for real to a CDN
Agreed. Anything other than serving it out of your SSR server. Serving it out of the server is a particularly bad idea because NextJS used to (not sure if it does it still) serve whatever it has for JS assets regardless of their checksum, which made non CDN rolling deploys very ... exciting.
Hi Jack, i'm a big fan of your micro-fes videos, thanks a lot.
Lately I got an Astro project to consume using Vite a Vue micro-fe exposed via Webpack with module federation. I am currently struggling to make it work with SSR.
Just wondering if you could provide some help with micro-fes and making them run in SSR mode (ie with Astro).
Best regards!
I would check with Fred and the Astro team on that, but my guess is that they probably don't think that's an awesome idea. Honestly, MFEs in SSR never really made much sense to me since I discourage using MFEs for mission critical page elements. So doing MFEs primarily on the client is ok with me. But hey, I don't know your use case, so if you require SSR then yeah, I'd reach out to that team.
Can you give an example of where you would need to use runtime sharing?
Because It seems like the cons stack is way more significant than the actual value we are getting here.
Also, if reusable components are shared across multiple repos shouldn't we extract them to entirely different Micro Frontend(library works here).
Great video!
For me a good example would be something like a product recommender carousel. Or even shared comments section.
Hey jack, thanks for the enlightning video, If you wanna go the opposite, I mean, to consume a module from webpack to vite, what would be the config in the vite project? If you have a reference it will be awesome, thanks.
Great work as usual, like your videos, if you have time I would be really interested in seeing video about deploying module federation app
I already have one of those in the Module Federation playlist.
Another great walkthrough. I've been coding along and I've initialised react ts project instead. It threw me a ts error. In order to correctly import the button I had to add a type declaration for it in my host project. I guess its because we load projects/modules dynamically at runtime and typescript doesnt know what are the types. Thanks a lot for the input and insights youre giving!
can you please tell me about your solution with typescript?
I liked your video, nice explanation, easy to follow, I would like to move one step forward, how to handle the errors like when remote app is down or not built, could you please post a video or comment on this, it will be really helpful, I am working on vite vue module federation
Thank you so much for video! This is super useful information🚀 What do you think about Vite and Turbopack? Which bundler more convenient for SPA?
Personally I'd rather go with Vite.
Hi Jack thank you for your video, please Jack could you tell us how to share data between host and microfrontend?
Truly an eye opener. Appreciate your video Jack.
Is there support for a Webpack 4 app to act as the host application ?
Yeah, it's totally interchangeable.
@@jherr Have you figured out a way maybe to use dynamic remotes with this plugin ?
Great video! Can you tell us wich browser are you using?
Arc.
Great tutorial! I have a question, lets say, if I expose a Micro-Frontend using Module Federation with Vite, can I consume it somehow from a Next.js application?
Hi sir, I'm creating a project with vite with vue3, i m using vite plugin SSR package, and implement the microfrontend with vite plugin federation, but error is occured, my error is file, data, node only allows with esm, not support http, how to solve this, please give the solution
Error when evaluating SSR module /component: failed to import "localhost:3002/dist/client/assets/remoteEntry.js"
|- Error: Only URLs with a scheme in: file, data, and node are supported by the default ESM loader. Received protocol 'http:'
at throwIfUnsupportedURLScheme (node:internal/modules/esm/load:239:11)
Any solution for this issue sir
Awesome video! About tree shaking, it seems like module federation struggles there too. Since we need to manually set up shared packages in each micro-app's bundling config as well as the host, it can cause duplicate packages downloaded by the client, right?
A good technique is to bring the package.json data into the vite.config and then just up Object.keys on the dependencies object to set up the shared array programatically. That way it's always kept in sync.
Tree shaking is clearly an issue. Not really sure what can be done about that. The module will include all the code in the exported module and anything local it depends on. And I wouldn't expect it to tree shake because it's impossible to know what will be called and what won't.
@Allysson dos Santos It sounds like in your case you should go with build-time dependencies. Because a given runtime library can't know which of its exports will be used, so it has to retain them all.
Well, now this is something useful. Thanks for sharing Jack! Quick non-related question: how did you manage to put the address bar on top of Arc browser?
That's the way it came for me. Do you mean the debugging stuff. That comes on automagically if you are looking at localhost.
Well, that's a nice easter egg 😂I was still using Firefox for development just because of that. Thanks a lot!
Loved this one !! I learned MFEs from your vdos only. Can we do a host - vite + react 18 + its own route and client - webpack + react 16 + its own route. Would be great if there is 1 vdo focused in different route strategies used in MFEs . Please guide if you have any info on this topic 🙂
Thanks for watching! Maybe this is just me but I don't think the MFEs as routes thing is a good idea. But if a lot of folks want me to cover that I certainly can. Technically speaking it's not that challenging.
Is that actually a window to outside behind you? That's beautiful! Where do you live?!?!
Portland, OR
I've spent some time with this trying to set up a remote app (vite) in a project where I don't control the host app (webpack). I got "SyntaxError: Cannot use "import.meta' outside a module (at remoteEntry.js:8:30)". At 9:50, line 9 in this video. Do you have any suggestions on how to get around that? I guess it's esm related, but I can't seem to figure out a way to solve it from the remote app.
Were you able to figure this out? I am getting same error
I really love your videos. I am just starting to learn about MFE. I would just like to ask if i can have different versions of react on host and app? lets say i have a legacy code that we can't upgrade the react version to be the same version as my MFE would that be an issue?
I see some projects using Module Federation within a Monorepo. Why would you do this if the monorepo (Turborepo) can manage the micro-frontend archictecture?
It would be great to see your take on solving runtime crashes when appling module federation.
There are lots of options around hardening. You can use ErrorBoundaries. You can do some fallback behavior to a lazily loaded import of the build-time module. But all that requires a lot of work to implement, test, and stay consistent with it. So it's a big commitment.
@@jherr and if there are some breaking changes in one of the libs some kind of versioning might be required. It seems like it becomes very complicated rather quickly. Sharing CSS seems like a pain too, as I understand it it has to be bundled with JS. Shared lob versions need to be synced between teams.
@@radulaski Yep, totally agree. That's why I put a section in this on pros/cons because there are a lot of cons. It's great to have access to this functionality, but it comes with a lot of risk and complexity. In a lot of my previous videos I didn't cover the downsides and folks came away thinking that Module Federation was way easier than using a monorepo. When in reality, it starts off being easier to share a component, but to actually get it hardened to production level, it's way harder than with a monorepo.
Thanks!
One big problem comes up when you open up the browser's sources tab and try to find a file and debug it, you won't find it
Vite and module federation still has an issue with dynamic remote containers.
I'm going to try this 😋
Thank you so much for this i could make it running but having problems with tests. any ideia how to test this in host applications ?
Джек как всегда хорош!!!
Спасибо за просмотр видео!
so, @jherr please let me so vite only provides build time sharing not runtime sharing? I tried loading the remotes dynamically in runtime, when I stops the remote the shell goes down!. I can't run both in dev mode, how I do with Webpack.
When using proper SolidJS functionality, I got it to build, but for some reason, it's not exposing the remoteEntry.js file at all (or even creating it in the /dist folder).
This specific plugin seems to be broken for React right now. React isn't correctly shared as a singleton causing deeper parts of the federated component tree to not detect it.
In other words, if the module you are exporting uses a React hook at any level below the top level; it will crash. Meaning a lot more complex apps will simply break if shared through this.
I have a wild idea I wanted to get some feedback on. We have several "core" apps that we currently use as stand alone MFEs. I've been trying to convince our team to switch our core apps to a monorepo.
With that in mind we allow customers to create third party apps to support their own needs. If we converted our core apps to a monorepo, we would still want to use module federation for stand alone MFE's. Could i combine this approach with a turborepo, the turborepo being the "remote" or atleast 1 app in the turborepo would be the remote? Is that over engineering?
single-spa uses in browser module resolution so effectively also doing run time module resolution. What are the benefits of this approach over that? It feels like single-spa has already done what module federation is trying to do now. But please feel free to correct me if my assumption here is wrong.
Single SPA is focused specifically on UI component sharing, and it is _fantastic_ at that. It also helps a lot with inter-framework development. So putting a Vue component on a React page is not a problem with Single-SPA. What Single-SPA doesn't do well is more low level sharing, if what you want to share is just logic, they don't have a model for that AFAIK.
FWIW, I see the two approaches as complimentary. Last time I checked Single-SPA could leverage Module Federation as a code transport method.
Also I think the import method for Module Federation is way cleaner than SystemJS.
Hello, Can you make react advance tutorial like optimization, memo and best practices, will really appreciate it, me and even who are looking the to level up their skills with concepts and practices
Hi Jack, super explained 🎉, can I say that Jotai is suitable for mono repos too ?
Yes, it's just a standard state manager. It's not specific to MFEs.
What do you think about using something like xState for shared state? I liked it as it was very easy to share the context and the various actions in one neat bundle while the component just implements the visuals and triggers for those actions and state.
Sharing state as it's primary purpose? That's not great, but if you state fits in the state machine model then go for it.
@@jherr Yes, we used it to pass a function that generated the machine (had some feature-flagging in there), and then it runs on the remote on its own.
Hi Jack! Great content thank you so much. From personal experience in a large project where you have many MFEs, some are "legacy" and using webpack 5 (including the host UI), there are some compatibility issues when introducing new UIs written in vite and MF plugin for vite. Is this something you're familiar with?
No, but then the extent of what I've done with Vite and MFEs is what you see right here. Can you tell me a little about what issues you experienced?
@@jherr I was talking about dynamic loading of module federation in vite (the remote UI is in vite)...
@@omriterem6448 I showed in the video that Vite MF can load Webpack MF. It's actually all dynamic to start, it's just that the loader is doing a little auto-magic when you do an import to load the module dynamically automatically. And so you should be able to do a dynamic module load. If you want to know how I recommend looking at the demo code provided by the Vite plugin folks or in Zack's demo project.
Hey Jack, I don't remember if I made this question in another video. I am using Vite and its module federation plugin. All works fine but when I try to run vitest as test runner I get an error trying to load the remote url, how I can mock that url and tell to my test that ignore the components from remote app used in the host application?
Just wondering, as you are using PNPM, why do you still use yarn for build tasks etc? Great vid btw!
Old habits die hard.
@Jack Herrington haha fair enough. Just finished implementing MF in my apps after watching your vid. Thanks!
Anyone tried Vite based module federation with Remix??? I cannot get assetUrl exposed, and “shared” is not allowing react and react-dom to be externalized
Nice! How do you share the user session to the mfe? Like a user profile and a shopping cart. User profile needs a session so does shopping cart. Can we do two-way-mfe ?
You could share the whole session object with an atom, but I'm not sure I would do that. I would create some atoms that pull out the specific data that the MFEs need so that an auth provider could change later.
So if we should build after each remote app change, can we not have HMR to watch changes live?
if I ask you do make a decision between for example ASTRO and MFE .... is it a valid question ? and if the answer is yes, what do you choose?
Thank you!
Do you have any resources on react typescript with vite mfe?
Hey Jack, thanks for this amazing video, can you share how you liked Arc as compared to safari or chrome
I like the tab management stuff, the embedded popup window, and the popout video in Arc as compared to Chrome. TBH, I don't use Safari enough to have a good opinion on it. I know some folks who have switched to Safari and love it, there is also the Orion browser, which folks are raving about. There is just too much good stuff out there!
@@jherr that’s a great insight thanks