I transformed my enterprise ERP solution from monolith create-react-app to micro-front-ends architecture with webpack 5 Module Federation: that was very risky move: we went through 3 weeks of red and blank screen of errors, rethinking some feature implementation, debugging MaterialUi Css, and re-working deployment pipeline to production, and added complexity to incoming junior developer... in total 3 month without updating our customer product. After that the effort and sacrifice worth it, the rate at which we implement new big feature or ERP module is scaled to 5x time faster, and we can work independently on single business domain. Thank You Jack, your channel helped me to take this strategic decision !
Hi bro I am also about to go through the hustle u have faced in mf app can pls tell me how u have managed redux when converting your app single feature to mico frontend so that they can be used by other module as well
@@amanbisht2606 To start with Micro-frontends is not "the solution" for all problems that we face at the app architecture level or at the code-base management level (which I will explain later) For redux you simply add redux store to host and every remotes apps and 'expose' your actions and 'reducers' through module-federation from host to the remotes . sharing at runtime some atomic components such (redux action, ui buttons, utility function...) will not leverage the full power of mfe, you still need to share code at build time: npm workspaces and monorepo work great with mfe, there is some "frameworks" for that: NX, Turborepo(not stable)... but it will add other layers of complexity to your stack, I' am still experimenting with it.
This is excellent. Item number four here, and your separate video on semantically versioned module federation, were incredibly helpful. I understand why you don't spend more time on detailing all of the different defensive strategies, but it is a good call out that the contract is something to be aware of.
I know that this is an older video (by YT standards), but I just have to say... if you're going to make the remote package and the host app both rely on a @types library then what's the point of module federation? Why wouldn't you just publish the remote app as a package and then make sure that the host updates... that way you can catch any errors created by a new version at build time rather than run time?
I love that you talked a bit about what this architecture looks like in a real deployed environment (ie. assets vs. server). Sometimes tutorials focus so much on the dev setup you forget a production-ready solution needs more than that. I'm also really curious about the sharing of types and if there is a way to share those types across repositories and projects. You could publish an NPM package with the types, and I'm sure you wouldn't be changing the type definitions as often as the components themselves. Would that be the only way?
NPM sharing is the most reliable way, and I think of it more as sharing type "contracts". There has also been some work on uploading zips of `.d.ts` files along with the federated modules, then pulling those down at compile time. I don't think any of that has been published.
Excellent work through of these issues. As someone behind the curve, I barely followed along on the code, but I understood from the explanations of the conditions for each scenario. Really impressive grip on your tools and frameworks in addition to being lucid on the solution architecture!
Thanks for great video, it helps a lot! I thought we could achieve microfrontend without shared repo, but as we use TypeScript - we need to have shared types, version them and deploy to each microapp?
On the final example of the library I don't think we saw the the failing state after having implemented the type in there and assigning it to the consumers. Is it correct that if one of those consumers (Modules) then didn't pass a user string prop into the MyUserMFE component that it would then fail the `yarn build`? p.s. tip for anyone using vscode, if you want to make a deep nests of directories for a file, when you right click in file explorer and choose create file and write it with the dirs you need like "deep/path/to/my/new-file.js" it'll automatically create the folders for you, hope it helps!
Yeah, I didn't test the failing state on the types. It would fail in the case where you have the mfe-shared, but it would not fail TS before that because the types are independently defined between host and remote.
This is good info. Knowing these things while adopting the technology is really helpful in avoiding some pitfalls. I did want to ask you one question around sharing router history. is that a thing? if a hosted app has its own internal routes how does that get captured? in an ideal world everyone would use the same stack and could pass around a router history object but if you have some apps on react, and others on vue, does that make it impossible to keep router history state?
I've got a 2hr module federation video coming out on freeCodeCamp soon and it includes a section on shared routing. I'll probably do another on this channel to compare React Router v6 and the new Tanstack react-location router.
Thanks Jack but I got a problem with my Tailwind, the Host component seems to be not apply the Tailwind to the remote component. I have tried using mini-css-extract but it's still not solved my problem
Thanks for your great videos. I followed the FMs and I am almost convinced it won't get any tractions. Besides the complexity in the last misconception you tried to fix a fundamental problem with runtime code sharing, i.e. guaranteeing the contract. And to solve it you had to go back to the old practice of sharing via libs. If I wanted to share code or contract via libs why would I need the FMs in the first place?
"If I wanted to share code or contract via libs why would I need the FMs in the first place?" Because you have a business requirement that specific components need to update across a multi-app architecture simultaneously? I'm not saying that we should use runtime sharing for everything. A project might only use it for one or two components. But even if it's just one, using an off-the-shelf architecture like Module Federation makes that much easier than any DIY/homebrew solution.
Not sure if this is a dumb question. But I got a question about prod deployment. Let's say a host app use a component from remote app. This component has changed the props, e.g. add a 'name' props and delete a 'email' props. So obviously I will update both host and remote app. But during prod deployment, which I assume we will deploy remote into S3 first, does it mean the host will have a brief time of error on the component until we finish host app deployment? Of course, we can use error boundary to wrap the host app. But still, would be good to be somehow avoid the down time.
I can't help but think related to the TS @types there must be an introspection or automated mapping to port over types to make it a bit easier with larger projects to maintain.
I think there will be a longer term fix for it. My hunch is we should be able to get a Webpack 5 module to output `.d.ts` modules to the output. And that there could be a fix, or experimental extension to `tsc` and the `tsconfig.json` to import the types from deployed URLs. That would fix the problem, with the exception of the federation module renaming that the host can do.
Thanks for watching all the way through. If you don't want to do the monorepo thing then you'll need to version and deploy the `mfe-shared` (or whatever you want to call the library of "contracts") to NPM or a private NPM. And then when you want to update those contracts you use `link` until you get everything working, then push new libraries with bumped versions. Alternatively, you could use a monorepo with good TypeScript support, like NX, and then doing this kind of work is trivial.
How we can share styles from shared components into entire app. like app1 holds reusable button, modal, table and some generic styles, Other apps like app2 should be able to apply classes directly and styles will be at one place in one app only which will be imported in shell app
For federated modules you either need to have a consistently loaded stylesheet between all the apps (e.g. custom, tailwind, material, etc.) or you need to use a CSS-in-JS approach since CSS is not federate-able. However, IMHO, you should not federate DSL components (e.g. button, modal, table, etc.) those should be NPM libraries or even externalized for fast sharing between applications.
Can you only define types for remotes in a monorepo? I have a situation where my remote code and host code are not in the same repo. Do I just need to define the types it in the host? I hope there is a cleaner way so it's more of a contract.
You can define those types in any build-time available resource, could be an NPM library, a local file, etc. The issue here is build-time vs run-time and it's not specific to Module Federation.
HI Jack, Thanks for a great videos on module federation and micro-front ends. looking for an example of MF with Angular and react. Can you please help with this?
Can we avoid single-spa if instead of trying to connect a react remote app to a vue host app (using module federation) we use web-components generated in react remote app and just use them from vue host app? Since they are web-components they are in theory just vanilla js. Would that be a good option?
With web components you don't even need to use federation. Although if you build them with React you'll want to make sure that you share the React library since it's a big payload. And for that you'll probably want to use something like Module Federation or SystemJS, just to manage shared dependencies between web components.
I have only seen this being done within the same project. I haven’t seen it with completely separate projects and I am having trouble getting it to work getting cors issues between the projects. Is that a limitation?
As always a fantastic video 👌👌 got 2 questions: I know you said the point of MF is not to deal with version upgrades. But would it be a safer if the error boundary could try lower versions before showing the alternative? When sharing types why not use linking when developing and in the production have it swapped use MF? Don’t know if it’s possible..?
"I know you said the point of MF is not to deal with version upgrades. But would it be a safer if the error boundary could try lower versions before showing the alternative?" I actually do have a video showing a pattern where, in the case on an error, the code asynchronously loads the NPM version and runs that. "When sharing types why not use linking when developing and in the production have it swapped use MF? Don’t know if it’s possible..?" I'm not following on this question.
@@jherr #1 answer: Nice! Found that. #2 answer: I mean you have your remote and host (no mfe-shared-lib). You then link the remote like you showed for the mfe-shared-lib. So allowing you to import the remote component. But when building it webpack swaps it out the import from a linked to a MF remote instead.
Great content 👍👍 What if I want to expose whole redux store from remote app how to do that....?? Since I want expose whole remote app along with store currently am only able to expose static hello world but not component which is connected to store...
Your video on Federated modules and single-spa cleared lot of my doubts. I thought these two are alternate frameworks for creating MFEs. But later i understood federated modules does help in creating external app modules but single spa in addition helps with managing entire MFE lifecycle. Working on MFEs for few months now. Everyone is fascinated about its result but not so confident in adapting it. Keep getting feedback that MFEs are still in preliminary state. Is it possible to make a video on security consideration in case of MFEs ? Since we are loading an external script in runtime, is there any security vulnerabilities you think of ?
As long as you are not making any cute tweaks to point the module loader at another URL then the security footprint of Federated Modules is the same as bundle splitting. So if the company is ok with bundle splitting it should be ok with federated modules.
@@jherr The external module is from a different application running on different server with it's own backend services . The frontend single spa is hosted within this external application and I'll be consuming in my application(shell). We r planning to configure both applications in a single domain through nginx to avoid cors.
@@mountakhabi sspa can basically handle when you need want mount or unmount an MFE application either by using single spa layout engine or through activeWhen. It also comes with its own set of custom events which can be used as lifecycle hooks.
Is it a right way to have module federated app running on different ports in docker (E.g. container app in 8080, child app in 8081) , and consuming the child app (8081) whenever we want? I did the config but the remoteEntry.js references the child app's js file to localhost:8080 instead of 8081 (Where the js files are actually present) as the publicPath i have specified in child app's webpack config is '/'.
I wouldn't use Docker to deploy federated modules. JavaScript code is a static asset and should be deployed to a static asset store (e.g. S3) and referenced from there. If you are talking about development, then, why Docker?
Yes. 100%. In the dashboard we render the connections exactly like that. The two-way dependency, where app A depends on B and B depends on A definitely make it a graph.
Great video, as always 👍One thing I still don't get about Module Federation and the production setup. The whole thing with starting multiple servers on different ports, yarn start etc. is good for development. But should you use the same setup in production? The ports could be different, maybe you need certificates and it always requires a full NodeJS environment. When building all modules to static JS, I think the production configuration has to be set beforehand and will be "hard coded" inside the bundled files. This could raise some security/auditing issues and is also not very flexible. I'm probably missing some major point on all this, but for me the benefit in favor of something like yarn workspaces and bundling everything to one big pile of static files is not obvious. Maybe someone can explain the production setup of Module Federation.
Check out this: ua-cam.com/video/MU8_LP8R_ZI/v-deo.html for the process on how to configure the URLs for production. The "hardcoded URL" is a tough solve IF you want to have the testing environment point at the testing deployed federated modules. But if you are ok with the test environment pointing at the production federated modules then it shouldn't be a problem. From a security perspective, if the CIS folks are ok with bundle splitting then they should be ok with federated modules. The deployment methodology is equivalent.
Can the static compiled js code be uploaded to a repo like S3 using versioning/convention, so that even if a new version of that mfe is released and possibly introduces breaking changes for a new consumer, the other hosts that stay "behind" won't break?
I have used unpkg in that style (as opposed to S3) and demonstrated that it does work in a video. So there are options for versioning. There are just none "out of the box" that I know of.
Hi Jack. Thanks for the great video! Sometimes people add some script tags in the index.html of theirs federated modules but we noticed that file is kind of ignored bythe time the component is imported into the app shell. Are there any workarounds for this ?
I don't fully understand the question. At this point however, you should not be injecting your federated modules using script tags on the page. I know my earlier videos showed it that way, but that is no longer the preferred way to go.
@@jherr thanks, also one other question. You metioned the diffeernce between single-spa and federation on the video. Do you have a dedicated video for single-spa in your channel? (example react host and one react and one vue/angular mfes).
Just like you mentioned in the video we like to avoid handholding the microfronds and have solution without getting the microfront ends involved too much (hopefully from a library or something, coming from the app shell)
Hi Jack I watched your videos with MF and I would like to know your opinion on the issue with a problem that I have had for a very long time. At the moment I have a very old web application that is written in javascript, pure javascript. I decided to rewrite the whole application in react but this process will take at least 2 years and I would like to start rewriting small parts of the application in react so that at some point I can give up the old application. How would you proceed in my situation?
I would get your application up on a decent bundler, like Webpack 5, Vite, Rollup, Parcel, whatever. And then I'd add a React app and "portal" it in to various parts of the page. reactjs.org/docs/portals.html That way you can replace segments of the page with React portals one by one. Not knowing your context any better this is probably the best answer I can give. Join the Discord server and ask your question in the #react channel if you want to provide more context and get a more refined answer.
Doesn't the need for sharing TS types through a library kind of ruin the use of MFEs? Because now the MFEs is not being developed in isolation anymore. Now you need to update a library when adding/updating types and then everyone that's hosting your remote has to update their dependencies to get the latest types?
@@yoda_zen There was some work done on a plugin that exported the .d.ts file into a zip file that would be located next to the federated module where it was located in production and then it would download the zip files for remote modules. I don't think that ever got published though. Honestly though, unless you NEED runtime modules I would just use traditional npm or monorepo tooling to get build time sharing. TypeScript is a solved problem in the build time sharing space.
Hello Jack, great stuff !! I am facing issue with hot reloading. I am using the react fast refresh library with webpack to enable live reload it works fine until you add config in shared section. even with webpack hot module replacement it doesn't update screen. Do you have any suggestion on this ??
Thanks for the great overview 👏🏻 Any thoughts on untrusted or semi trusted modules? So for example if a third party is developing a component you want to embed, my knee jerk react would be to put it in an . But do you see a way to do that with module federation securely?
i don't really have an answer for you on that one. MF is just a code sharing mechanism, so whatever you can do in JS to sandbox some other JS, then that will work.
About that 'platform agnosticism' and using Webpack's Module Federation... I've been following along several of your videos and I think I like it, but there's one thing that kind of bugs me: When you're exposing modules and components with this, it seems that you're also forced to consume these modules with an application that's been build with Webpack, or not? I really like the idea of having an asset store that can be use by anyone, but being forced to also use Webpack to consume these modules, I don't know? (Although Webpack for me is the only thing that I can decently work with)
I transformed my enterprise ERP solution from monolith create-react-app to micro-front-ends architecture with webpack 5 Module Federation: that was very risky move: we went through 3 weeks of red and blank screen of errors, rethinking some feature implementation, debugging MaterialUi Css, and re-working deployment pipeline to production, and added complexity to incoming junior developer... in total 3 month without updating our customer product.
After that the effort and sacrifice worth it, the rate at which we implement new big feature or ERP module is scaled to 5x time faster, and we can work independently on single business domain.
Thank You Jack, your channel helped me to take this strategic decision !
any pain points with MF in yor experience?
Hi bro I am also about to go through the hustle u have faced in mf app can pls tell me how u have managed redux when converting your app single feature to mico frontend so that they can be used by other module as well
@@amanbisht2606 To start with Micro-frontends is not "the solution" for all problems that we face at the app architecture level or at the code-base management level (which I will explain later) For redux you simply add redux store to host and every remotes apps and 'expose' your actions and 'reducers' through module-federation from host to the remotes .
sharing at runtime some atomic components such (redux action, ui buttons, utility function...) will not leverage the full power of mfe, you still need to share code at build time: npm workspaces and monorepo work great with mfe, there is some "frameworks" for that: NX, Turborepo(not stable)... but it will add other layers of complexity to your stack, I' am still experimenting with it.
@@yassinebouchoucha thanks for replying so you are saying create redux store for each microfrontend app
One of the best videos which explains Module Federation concept. Now I finally know where I did my mistakes in a solution. Thanks!
This is excellent. Item number four here, and your separate video on semantically versioned module federation, were incredibly helpful.
I understand why you don't spend more time on detailing all of the different defensive strategies, but it is a good call out that the contract is something to be aware of.
What's that video about semantic versioning?
I know that this is an older video (by YT standards), but I just have to say... if you're going to make the remote package and the host app both rely on a @types library then what's the point of module federation? Why wouldn't you just publish the remote app as a package and then make sure that the host updates... that way you can catch any errors created by a new version at build time rather than run time?
I love that you talked a bit about what this architecture looks like in a real deployed environment (ie. assets vs. server). Sometimes tutorials focus so much on the dev setup you forget a production-ready solution needs more than that. I'm also really curious about the sharing of types and if there is a way to share those types across repositories and projects. You could publish an NPM package with the types, and I'm sure you wouldn't be changing the type definitions as often as the components themselves. Would that be the only way?
NPM sharing is the most reliable way, and I think of it more as sharing type "contracts". There has also been some work on uploading zips of `.d.ts` files along with the federated modules, then pulling those down at compile time. I don't think any of that has been published.
Nx's module federation boilerplates have cross-module typescript coverage.
That error boundary tip was new to me. Thank you very much
This is high-quality. Thank you
Excellent work through of these issues. As someone behind the curve, I barely followed along on the code, but I understood from the explanations of the conditions for each scenario. Really impressive grip on your tools and frameworks in addition to being lucid on the solution architecture!
Thank you, and I'll keep plugging away at this stuff trying to make it as comprehensible as I can. :)
Thanks for great video, it helps a lot! I thought we could achieve microfrontend without shared repo, but as we use TypeScript - we need to have shared types, version them and deploy to each microapp?
Do you have a video covering routing with MFEs? Trying to figure out how you would export your routes or guarded routes from remote.
On the final example of the library I don't think we saw the the failing state after having implemented the type in there and assigning it to the consumers. Is it correct that if one of those consumers (Modules) then didn't pass a user string prop into the MyUserMFE component that it would then fail the `yarn build`?
p.s. tip for anyone using vscode, if you want to make a deep nests of directories for a file, when you right click in file explorer and choose create file and write it with the dirs you need like "deep/path/to/my/new-file.js" it'll automatically create the folders for you, hope it helps!
Yeah, I didn't test the failing state on the types. It would fail in the case where you have the mfe-shared, but it would not fail TS before that because the types are independently defined between host and remote.
Jack, Thanks for making this video.
This is good info. Knowing these things while adopting the technology is really helpful in avoiding some pitfalls. I did want to ask you one question around sharing router history. is that a thing? if a hosted app has its own internal routes how does that get captured? in an ideal world everyone would use the same stack and could pass around a router history object but if you have some apps on react, and others on vue, does that make it impossible to keep router history state?
I've got a 2hr module federation video coming out on freeCodeCamp soon and it includes a section on shared routing. I'll probably do another on this channel to compare React Router v6 and the new Tanstack react-location router.
@@jherr awesome! this is something I've really had a hard time wrapping my head around... so I'll wait patiently.
Thanks Jack but I got a problem with my Tailwind, the Host component seems to be not apply the Tailwind to the remote component. I have tried using mini-css-extract but it's still not solved my problem
same problem here , did you find a solution
Thanks for your great videos.
I followed the FMs and I am almost convinced it won't get any tractions.
Besides the complexity in the last misconception you tried to fix a fundamental problem with runtime code sharing, i.e. guaranteeing the contract.
And to solve it you had to go back to the old practice of sharing via libs.
If I wanted to share code or contract via libs why would I need the FMs in the first place?
"If I wanted to share code or contract via libs why would I need the FMs in the first place?" Because you have a business requirement that specific components need to update across a multi-app architecture simultaneously?
I'm not saying that we should use runtime sharing for everything. A project might only use it for one or two components. But even if it's just one, using an off-the-shelf architecture like Module Federation makes that much easier than any DIY/homebrew solution.
Not sure if this is a dumb question. But I got a question about prod deployment. Let's say a host app use a component from remote app. This component has changed the props, e.g. add a 'name' props and delete a 'email' props. So obviously I will update both host and remote app. But during prod deployment, which I assume we will deploy remote into S3 first, does it mean the host will have a brief time of error on the component until we finish host app deployment? Of course, we can use error boundary to wrap the host app. But still, would be good to be somehow avoid the down time.
Thanks Jack! For Q4 I'm rolling out MF for my team.
I can't help but think related to the TS @types there must be an introspection or automated mapping to port over types to make it a bit easier with larger projects to maintain.
I think there will be a longer term fix for it. My hunch is we should be able to get a Webpack 5 module to output `.d.ts` modules to the output. And that there could be a fix, or experimental extension to `tsc` and the `tsconfig.json` to import the types from deployed URLs. That would fix the problem, with the exception of the federation module renaming that the host can do.
Wow Jack you fly through these videos, you definitely know your sh!t. Great content!
About yarn link in the end.
Say I have 2 projects in different repos and a third repo for shared lib. How can we link for types in such a case?
Thanks for watching all the way through. If you don't want to do the monorepo thing then you'll need to version and deploy the `mfe-shared` (or whatever you want to call the library of "contracts") to NPM or a private NPM. And then when you want to update those contracts you use `link` until you get everything working, then push new libraries with bumped versions.
Alternatively, you could use a monorepo with good TypeScript support, like NX, and then doing this kind of work is trivial.
The video is very good. Thanks share! I have a question, what is the advantage over NPM? It is unstable and Typescript also depends on NPM.
Runtime sharing is the big win here. But not everything needs that runtime sharing. It's just a good thing to have in your tool bag when you need it.
@@jherr got it, thanks
How we can share styles from shared components into entire app. like app1 holds reusable button, modal, table and some generic styles, Other apps like app2 should be able to apply classes directly and styles will be at one place in one app only which will be imported in shell app
For federated modules you either need to have a consistently loaded stylesheet between all the apps (e.g. custom, tailwind, material, etc.) or you need to use a CSS-in-JS approach since CSS is not federate-able. However, IMHO, you should not federate DSL components (e.g. button, modal, table, etc.) those should be NPM libraries or even externalized for fast sharing between applications.
Can you only define types for remotes in a monorepo? I have a situation where my remote code and host code are not in the same repo. Do I just need to define the types it in the host? I hope there is a cleaner way so it's more of a contract.
You can define those types in any build-time available resource, could be an NPM library, a local file, etc. The issue here is build-time vs run-time and it's not specific to Module Federation.
thank you for this valuable information , well explained
Thanks!
Thanks for the explanation and examples :)
HI Jack,
Thanks for a great videos on module federation and micro-front ends.
looking for an example of MF with Angular and react. Can you please help with this?
I faced loading script failed issue. but i step by step follow your way can't work this command "PORT=3001 npx servor" why?
what shall I do?
Can we avoid single-spa if instead of trying to connect a react remote app to a vue host app (using module federation) we use web-components generated in react remote app and just use them from vue host app? Since they are web-components they are in theory just vanilla js. Would that be a good option?
With web components you don't even need to use federation. Although if you build them with React you'll want to make sure that you share the React library since it's a big payload. And for that you'll probably want to use something like Module Federation or SystemJS, just to manage shared dependencies between web components.
In case I use module federation, should I keep Single-spa if all my MFE are in React only ?
React-only IMHO.
I have only seen this being done within the same project. I haven’t seen it with completely separate projects and I am having trouble getting it to work getting cors issues between the projects. Is that a limitation?
You should check NX Monorepos and its integration with Module Federation.
Yeah, the Angular integration is great. The React integration isn't as awesome from what I've seen.
As always a fantastic video 👌👌 got 2 questions:
I know you said the point of MF is not to deal with version upgrades. But would it be a safer if the error boundary could try lower versions before showing the alternative?
When sharing types why not use linking when developing and in the production have it swapped use MF? Don’t know if it’s possible..?
"I know you said the point of MF is not to deal with version upgrades. But would it be a safer if the error boundary could try lower versions before showing the alternative?" I actually do have a video showing a pattern where, in the case on an error, the code asynchronously loads the NPM version and runs that.
"When sharing types why not use linking when developing and in the production have it swapped use MF? Don’t know if it’s possible..?" I'm not following on this question.
@@jherr
#1 answer: Nice! Found that.
#2 answer: I mean you have your remote and host (no mfe-shared-lib). You then link the remote like you showed for the mfe-shared-lib. So allowing you to import the remote component. But when building it webpack swaps it out the import from a linked to a MF remote instead.
@@Norfeldt I think that #2 is possible with some webpack shenanigans. Not sure I would recommend that though.
Great content 👍👍
What if I want to expose whole redux store from remote app how to do that....??
Since I want expose whole remote app along with store
currently am only able to expose static hello world but not component which is connected to store...
Your video on Federated modules and single-spa cleared lot of my doubts. I thought these two are alternate frameworks for creating MFEs. But later i understood federated modules does help in creating external app modules but single spa in addition helps with managing entire MFE lifecycle.
Working on MFEs for few months now. Everyone is fascinated about its result but not so confident in adapting it. Keep getting feedback that MFEs are still in preliminary state.
Is it possible to make a video on security consideration in case of MFEs ? Since we are loading an external script in runtime, is there any security vulnerabilities you think of ?
As long as you are not making any cute tweaks to point the module loader at another URL then the security footprint of Federated Modules is the same as bundle splitting. So if the company is ok with bundle splitting it should be ok with federated modules.
@@jherr The external module is from a different application running on different server with it's own backend services . The frontend single spa is hosted within this external application and I'll be consuming in my application(shell). We r planning to configure both applications in a single domain through nginx to avoid cors.
What do you mean by single-spa helping with managing entire MFE lifecycle ? How it help ?
@@mountakhabi sspa can basically handle when you need want mount or unmount an MFE application either by using single spa layout engine or through activeWhen. It also comes with its own set of custom events which can be used as lifecycle hooks.
Is it a right way to have module federated app running on different ports in docker (E.g. container app in 8080, child app in 8081) , and consuming the child app (8081) whenever we want?
I did the config but the remoteEntry.js references the child app's js file to localhost:8080 instead of 8081 (Where the js files are actually present) as the publicPath i have specified in child app's webpack config is '/'.
I wouldn't use Docker to deploy federated modules. JavaScript code is a static asset and should be deployed to a static asset store (e.g. S3) and referenced from there. If you are talking about development, then, why Docker?
Would you say that Module Federation should be more like a graph rather than a tree?
Yes. 100%. In the dashboard we render the connections exactly like that. The two-way dependency, where app A depends on B and B depends on A definitely make it a graph.
Great video, as always 👍One thing I still don't get about Module Federation and the production setup. The whole thing with starting multiple servers on different ports, yarn start etc. is good for development. But should you use the same setup in production? The ports could be different, maybe you need certificates and it always requires a full NodeJS environment. When building all modules to static JS, I think the production configuration has to be set beforehand and will be "hard coded" inside the bundled files. This could raise some security/auditing issues and is also not very flexible. I'm probably missing some major point on all this, but for me the benefit in favor of something like yarn workspaces and bundling everything to one big pile of static files is not obvious. Maybe someone can explain the production setup of Module Federation.
Check out this: ua-cam.com/video/MU8_LP8R_ZI/v-deo.html for the process on how to configure the URLs for production.
The "hardcoded URL" is a tough solve IF you want to have the testing environment point at the testing deployed federated modules. But if you are ok with the test environment pointing at the production federated modules then it shouldn't be a problem.
From a security perspective, if the CIS folks are ok with bundle splitting then they should be ok with federated modules. The deployment methodology is equivalent.
@@jherr Thank you for your reply. I've watched your video and it's now clear to me 😁It's still possible to serve static files 👍
Can the static compiled js code be uploaded to a repo like S3 using versioning/convention, so that even if a new version of that mfe is released and possibly introduces breaking changes for a new consumer, the other hosts that stay "behind" won't break?
I have used unpkg in that style (as opposed to S3) and demonstrated that it does work in a video. So there are options for versioning. There are just none "out of the box" that I know of.
Hi Jack. Thanks for the great video! Sometimes people add some script tags in the index.html of theirs federated modules but we noticed that file is kind of ignored bythe time the component is imported into the app shell. Are there any workarounds for this ?
I don't fully understand the question. At this point however, you should not be injecting your federated modules using script tags on the page. I know my earlier videos showed it that way, but that is no longer the preferred way to go.
@@jherr thanks, also one other question. You metioned the diffeernce between single-spa and federation on the video. Do you have a dedicated video for single-spa in your channel? (example react host and one react and one vue/angular mfes).
Just like you mentioned in the video we like to avoid handholding the microfronds and have solution without getting the microfront ends involved too much (hopefully from a library or something, coming from the app shell)
@@samparhizkar5221 Here are two ua-cam.com/video/wxnwPLLIJCY/v-deo.html and ua-cam.com/video/wU06eTMQ6yI/v-deo.html
Hi Jack
I watched your videos with MF and I would like to know your opinion on the issue with a problem that I have had for a very long time.
At the moment I have a very old web application that is written in javascript, pure javascript. I decided to rewrite the whole application in react but this process will take at least 2 years and I would like to start rewriting small parts of the application in react so that at some point I can give up the old application.
How would you proceed in my situation?
I would get your application up on a decent bundler, like Webpack 5, Vite, Rollup, Parcel, whatever. And then I'd add a React app and "portal" it in to various parts of the page. reactjs.org/docs/portals.html That way you can replace segments of the page with React portals one by one.
Not knowing your context any better this is probably the best answer I can give. Join the Discord server and ask your question in the #react channel if you want to provide more context and get a more refined answer.
@@jherr Thanks Jack for the answer! You're doing a good job with this channel. I appreciate
Doesn't the need for sharing TS types through a library kind of ruin the use of MFEs? Because now the MFEs is not being developed in isolation anymore. Now you need to update a library when adding/updating types and then everyone that's hosting your remote has to update their dependencies to get the latest types?
No, because the types ensure the contracts between the app and the MFEs and not the implementation.
@@yoda_zen There was some work done on a plugin that exported the .d.ts file into a zip file that would be located next to the federated module where it was located in production and then it would download the zip files for remote modules. I don't think that ever got published though. Honestly though, unless you NEED runtime modules I would just use traditional npm or monorepo tooling to get build time sharing. TypeScript is a solved problem in the build time sharing space.
Good solution thanks
Hello Jack, great stuff !! I am facing issue with hot reloading. I am using the react fast refresh library with webpack to enable live reload it works fine until you add config in shared section. even with webpack hot module replacement it doesn't update screen. Do you have any suggestion on this ??
I haven't really looked into HMR with Module Federation in detail, sorry.
I've seen a lot of your videos. In my understanding, all these tools were created so we can implement counters in many different ways.
Does "mfe-shared" not even have to appear in package.json of host and remote?
Yes.
Thanks, Jack Gr8 Video!! :)
Thanks for the great overview 👏🏻 Any thoughts on untrusted or semi trusted modules? So for example if a third party is developing a component you want to embed, my knee jerk react would be to put it in an . But do you see a way to do that with module federation securely?
i don't really have an answer for you on that one. MF is just a code sharing mechanism, so whatever you can do in JS to sandbox some other JS, then that will work.
is monorepo a requirement for MF?
Nope.
I am stuggling to deployement module federation app
You can join the #module-federation channel on my Discord server to request help with this. Please read the #rules before posting.
About that 'platform agnosticism' and using Webpack's Module Federation... I've been following along several of your videos and I think I like it, but there's one thing that kind of bugs me: When you're exposing modules and components with this, it seems that you're also forced to consume these modules with an application that's been build with Webpack, or not? I really like the idea of having an asset store that can be use by anyone, but being forced to also use Webpack to consume these modules, I don't know? (Although Webpack for me is the only thing that I can decently work with)
You can make a Webpack 5 shim build and then dynamically load the modules. But you need to be sure to pass your shared library into the initialize.
Making me want to move to Organ with that view