Hi Jack, Thanks for putting out these videos. I wanted to get into the frontend architecture but wasn't able to find the correct path. I think you hold great knowledge. Thanks for sharing it with us.
Wow thank you for the clear explanation, my graduation internship project is about micro-frontends and this will be perfect for one of my use cases, I'm excited to implement it 🥳
That’s pretty cool. Lol 2 years later and I’m just learning about this. I work more in the server-side end of things so… What are your thoughts about web assembly?
Although this is a very cool way to share code, I am still very skeptical on the governance at the organizational level. If each app is managed by two different teams, doesn't that mean that one team is now managing the dependency of the other? What if the Home app no longer wants to use ProductCarousel? Are they forced to keep the component within the Home codebase even though it's obsolete? Should the ProductCarousel be transferred to another team? Would that force any other teams using ProductCarousel to have to update their code? Why should be the Home app be the owner of this dependency and not the Search app? I have many questions.
It means all of that, but it's not clear to me how that's any different from NPM. The only difference between NPM and MF in this case is that with NPM the code exists in another library, whereas in MF the code exists in the app. From my experience the pain points of jumping back and forth between a library and the consuming application to get a bug fixed is far worse than ownership concerns over an exposed component. Also, at the large organization level the "ownership" of code is a big ongoing concern and not taken lightly. So if team A decides to take on building and owning ProductCarousel long term then it's probably a big part of what they do.
Hi Jack, I´m from Colombia. I have a sentence that I think is correct. Module Federation is a way to share logic or visual components in the front end, that is similar, but no equals, to Microfrontends (MF). When we talk about MF we are talking about isolated applications living together in a container. Each one app is a domain. If you want to share small capabilities, you should use module federations for example, but if you want to share whole app about a buisiness domain, you should use MF strategy. Can you tell me if I am right? Thanks, nice video.
Very cool about Colombia. Let me give my one sentence synopsis: Module Federation is a code transport layer that can be used for Micro-Frontends (as well as many other uses for shared code.) And then a little extra; Module Federation does not provide a view platform agnostic capability like Single SPA which is required when you want to run MFEs from different view stacks on the same application. For example, a Vue application that hosts a React MFE.
Thank you Jack for a clear explanation of the subject. However, I have a tricky question. The thing is that I'm a bit worried about dependency re-usage. Right now, it's not clear how exactly this mechanism is working. It looks straightforward when there is no needed dependency found in the host project, the system will load it from the remote. But how does it works when there is a dependency in both apps, but the version differs? Is there a way to check for version compatibility somehow (using semver?) or will it just load the dependency blindly (and possibly break the app due to a versions missmatch)? The other question that really worries me is how does it work with tree-shaking? The thing is that each application uses only a subset of the library in question, the other part of the library is just removed from the bundle (consider lodash-es). What will happen if the system would try to use the tree-shaken dependency from the host application and will call a symbol that was removed from the bundle? This looks pretty dangerous, especially considering the fact that the binding happens in runtime and both apps change independently.
Webpack does a really good job with dependency resolution and it gives you a number of rules you can apply to manage the dependency overlaps. On the tree shaking side I'm not sure. The best person to answer questions like that is Tobias Koppers or the Webpack support community.
@@jherr thank you for a quick reply. I guess I will escalate my question regarding the tree-shaking then :) Considering the dependency resolution in federated apps, is it documented somewhere?
@@slavafomin Yep. You can take a look at a lot of examples here: github.com/module-federation/module-federation-examples And we have a book out on Module Federation: module-federation.myshopify.com/ Also, this particular video is very old. I think this was the first video I did on it and that was pre-alpha. So you may want to look at some later videos in my Module Federation playlist to get a sense of what the released system looks like.
@@jherr that's great, thank you. Do you have maybe a Kindle version of the book? :) Also, do you consider this technology production ready? Do you know if some serious companies are using it in the wild?
@@slavafomin The Kindle format didn't work well for the book. :( I do know of one big e-Commerce company using it in prod. And is released, maintained, and gradually attracting more and more interested based on book sales which have been steadily increasing.
Great video! I think I understand the concept but what would happen if say a component that is used in another page is modified and breaks the implementation on pages that are dependent on it. Also, as component sharing increases, would the component's author need to be notified that their components are being used elsewhere so some sort of versioning needs to be implemented for the respective component? I guess one page can be designated for sharing so that every component version is retained but then I don't see why that isn't already done with existing monolithic implementations.
Nvm, I watched your versioning video. I still don't get the primary advantage of MF other than not having to update package.json. Feels a lot like deno's remote imports.
Deno still downloads versions for build and run. The big win with MF is that it establishes runtime dependencies. Which are super important in multi-team multi-app situations because there is a need to release some components or code simultaneously across all the applications. And it's runtime dependencies that can get you there.
Not sure how does this differs from the Bazel. I can already to make hermetic app-shells and reusable widgets and components, which i can throw in wherever i want. To use dynamic imports, reducer injection and other things. Sure, it's mono-repo centric so everything becomes shareable. On top of that i can build Protobuf type declarations and share them between FE and BE with ease. If any single shared piece gets updated, then chain of incremental builds is triggered testing every consumer of that updated lib/component/whatever. Single tool for the all build and deployment requirements for booth, the back-end and front-end. The only use-case i can see so far is related to local DX. Like.. simplified version of spinning up dev environment locally. But.. definitely really interested to dig deeper into this. Nice stuff.
@@jherr That is it. No. It's multi-language build system with good TypeScript support, etc. Large Angular projects (and React, etc) are commonly managed with Bazel. It's not the simplest tool for the first day, but... not that complex if you spend some time. I myself found it bit similar to Ansible. :) You can do all the crazy things with it by writing your own rules if you wish. Rules_nodejs and ts_library is a good starting point for the TS projects. Ouh... one thing... it's mono-repo centric... You can have multiple workspaces, but overall all the code sharing features comes out of this fact.
@@Oswee Oh, interesting. I'd love to see it if you have a repo I can clone and try out. One very big difference would be that Module Federation doesn't require the mono-repo.Most of the examples use them because it's just easier to deal with in a learning context. But in reality you can have different teams, working in different repos, deploy to production independently. Then those teams in turn could use components directly exported from each others applications (not externalized into libraries).
@@jherr I am working on some "boilerplate" setup with Web Components, Redux modules, Protobufs and Go, but it's still in quite messy state. Yeah... poly-repo setups has it's own niceties. I went into Bazel exactly because of Lerna and inability to build Protobuf TS type declarations. I mean... in order to use types in BE and FE i must build and publish every package on every change. Then i should pull them down. Etc. Gets really messy. So... what i found is that Bazel can do all of that for me which from DX point is a great deal. I don't need yarn workspaces, lerna etc. Single tool. Especially important for full-stack polyglot setups. Downside is that it's harder to enforce some "RBAC" for teams. (I'm not in that envirionment). Because of my old habbits i implemented webpack-dev-server into my bazel setup. It works. But... it somewhat feels wrong... So today i went back to research, saw this federation thing, but ... the big picture does not come together anymore. I have some gap in order to understand do i really need webpack at all. All artifacts are build by Bazel. So... what should i use webpack for? Bundling? No... bazel does that. Probably local serving... but... i also start to doubt that. With the same success i can bundle it into Go container and deploy it anywhere (of course with the same tool). Or... make a volume mount directly to the artifacts (lol). If i would be still in the Lerna & Co world the for sure i would deep dive into Federation. But unfortunatelly now i have more questions than answers. Can't wait tomorrow to keep my research. :)
@@Oswee Cool. Really looking forward to seeing whatever you come up with! I think the difference is that in the e-Commerce environment where I'm normally operating we already have multiple React apps (micro-sites) across multiple repos and all of them are already being webpacked. Within that "micro-site" architecture sharing becomes a huge pain. So Module Federation just adds this extra additional feature of being able to share code much more easily within the context of that setup.
Thanks for the awesome video, I have a question for you. Does this allow for different npm module dependency versions? Let's say the "Home" team needed to use a more recent version of Material UI than the "Search" team. Would they just remove it from the shared array in ModuleFederatedPlugin? My bad if I missed that your video.
That is really impressive Jack. Thanks a lot for this. I have a question: Would it be possible to use this approach for theming with sass variables? Example: - My Bundle contains a bunch of UI Components using sass with some variables set to default values and also imports a "federated (remote) scss file". - My app uses Bundle1 and provide the remote scss that overrides some of those sass variables I'm not sure if this is feasible but it would be really cool!
Great thanks for the walkthrough! One question. I read that federation defaults to what it can find locally. So would this still work in a PWA? I assume I couldn't use lazy loading as that may cause an issue if the app / site was loaded then went offline before all the modules were loaded.
From a devops perspective Module Federation is just elaborate bundle splitting. Your modules are just JavaScript files that are deployed to static asset stores (e.g. S3). So if S3 goes down before all your assets are loaded, that I guess would be a problem.
Assuming you are using something like React and you are sharing your auth state is context. Then that auth provider can be a federated module itself which is shared by both the host application and any MFEs through traditional context. Or if you are doing the Redux thing you can make it a part of the store.
I'm curious how do we use micro-frontends with Module Federations across different repos? Say you have Home and Search on different repos. How would Home leverage code from Search compiled from a separate repo
Mono repo or different repos doesn't really matter. What matters is the deployed location. In the demos I "deploy" to localhost and depend on it from there. But in production you would deploy to an S3 bucket (or equivalent) and depend on that URL.
It's been 3 years already but still great content! I have two questions. Is it possible to share other static files besides JS files? I see the fruit images are stored in the home app. How is the search app able to render those images since they're not available locally? Maybe I'm missing something...
@@jherr So it wouldn't be able to get the images if the home app server was down, right? But I guess that's just for the demo. In a real-world app the remote exposed files (JS included) would be stored in a static asset store as you've just said. Got it! Thanks!
@@viniciusneto6824 correct. In a correctly deployed real world scenario you would not run into this “it’s down” scenario unless your static asset server fell over (unlikely in the case of S3) or if the assets were errantly removed. Also a CDN is another good option here and also provides a ton of stability.
Thanks for this video! A question that's come up within my organization is around reusing components across CRM apps (think Salesforce implementation) that serve a certain set of personas (think CSRs) and customer facing apps (think Web and Mobile apps that are deployed for self-service by the customer). I presume that that is doable assuming all things being equal - data being presented to the personas. I've not gotten good references around embedding such a micro front end within Salesforce or vice versa. Any pointers appreciated.
Have you ever looked into doing module federation in a serverless environment? It seems like serving up federated parts to consume from a serverless environment would be a good match. But the last time I did any real learning about serverless was 4+ years ago - so maybe I have my head in the clouds... ;-)
Hello Mr. Herrington My micro-projects are exposed on the server and the project they are remote is in my local, my problem is that fonts are not displayed in my local project Which part do you think has a problem?
Module federation shares JavaScript modules. And that doesn’t include css unless you do css in JS. And I don’t think it can do fonts at all. So you’d need to have the host and remote apps both include the same fonts.
I have a HOST app with angular material 13.1.x, and a remote app with angular material 13.1.y On import i get "Uncaught SyntaxError: Cannot use 'import.meta' outside a module" Is there a way to keep updating remote packages and let the host app sit with a lower package version?
Not sure. I don't do a ton with Angular. You might want to check out the folks behind this module: www.npmjs.com/package/@angular-architects/module-federation
Great video! I am curious... What does federation do that something like Lerna can't already do? Lerna can link dependencies locally so I'm trying to see the difference here. Thanks!
Lerna works at build time. So in order to see changes in shared code you'd need to re-deploy any applications that rely on that code. In the federated model, once the application that hosts the code is updated then any applications consuming that code would get the update immediately. (There are inherent risks with this approach. ;) )
Indeed this is my question too. I think solving this at build-time with a monorepo is a much safer strategy. And it makes it more clear where the dependencies are coming from. I'm curious what the real-world use case for this is. A giant company where teams don't speak to each other and work on various repos -- but still want to share code?
@@jherr I see. I am also wondering if module federation helps in creating a SPA app which has several micro front-ends as separate pages, have some shared components (published in as a separate npm package) and a library like React? Is it possible to name entire packages as shared dependencies in the ModuleFederationPlugin?
@@DK-ox7ze You have to expose modules one by one, unless you want to expose an "index"-style route that has multiple exports. There is also the "shared" key in the configuration that defines the libraries you want to share, and those are shared completely.
Can't stop thinking about how this will integrate with a CI setup? If a component is shared to other applications and is updated, is there any way for the other applications to run their e2e tests and then decide to implement the update or stay on the older version?
On the stability side, you can use a fallback pattern I described in the "resilient header" video (th-cam.com/video/K-yQB9YGmgE/w-d-xo.html). In that video I show how to use a potentially stale npm copy as a backup using error boundaries. On the CI side, yeah, you are always pushing the `remoteEntry.js` to a well known stable location, and then that `remoteEntry.js` might point to different chunk names on each build. There is a project called the Module Federation Dashboard which tracks who depends on what federated modules and also allows you to do a rollback if there is an issue in production. The requirement for E2E testing isn't specific to this approach to Micro-FEs. All runtime dependency systems (OpenComponents, SingleSPA, Module Federation, SingleSPA + Module Federation, etc.) are going to need runtime smoke tests and error monitoring after the deploy.
@@jherr Sorry! I totally forgot to thank you very much for your knowledge sharing and great content! Just had the question in my head and needed to get it down.
@@Norfeldt Oh hey, no worries at all. Totally fine. Thank you for the view, and let me know if there is more content that you would like to see that might help you. I think my most recent video on Micro-FEs Simplified (th-cam.com/video/tFDvEITdJZ8/w-d-xo.html) represents the best I've done on this topic. Though I am doing a Vue version of that coming up that I'm super excited about.
@@jherr Great to hear. I'm personally very interesting in react and testing (as you might have guessed) - I'm finding every excuse/good side projects to play around with cypress (like unit tests, but find the cypress e2e approach very intuitive), so loved that you did some e2e testing with that in one of you federal modules videos . Just discovered you channel recently and must say I find the content really exciting 🙌👏👍
@@Norfeldt Thanks! All I ask is that you let other people know who might be interested in the content. :) And yeah, I did do the E2E tests in the Full Site Federation video because that's actually a real win for Module Federation. When we went to micro-sites we lost the ability to do a full E2E test before deployment. But MF actually brings that back. You can test updates to one micro-site and use the production code from the other micro-sites and do a complete E2E smoke test through the entire site even across micro-sites. Very cool stuff.
Can we do this purely for server side code? Say a remote app exposes an express middleware and the host app remotely runs the middleware on server side?
Where did you specify the port number of the other applications? I understand that Webpack is exposing certain components from the app's bundle, but how does the consuming code (app) resolve the exposed components?
@@jherr I see. Could you also explain how code is shared between local webpack bundles (i.e. bundles part of the same app)? Say there are two bundles - bundleA, and bundleB. Both require React, but React is only included in bundleA. So how will bundleB refer React from bundleA?
@@DK-ox7ze As long as react is listed as a shared library between host and remote Webpack handles reusing (and not re-downloading) the react instance. Which is particularly important in that example because react is a singleton and you cannot have two versions of react within the same application.
@@jherr Yeah I understand that React is shared between bundles, but what I meant is, what's the mechanism of this sharing? Given that all of webpack bundle's code is self isolated (as it's encapsulated in an IIFE), how are two bundles able to refer code from other bundles?
Just the same way as any other component. Module Federation doesn't manage the environment around your code. It just allows you to share code. You would need to set it up so that the host application provided the appropriate store.
@@jherr I have remote app which is connected to store and middle wares which are already written....now I have to expose this whole app to host basically store is in remote...??i heard in run time we can inject reducers and sagas But limited docs on that how to proceed??
@@hk_build This is not a Module Federation problem. Module Federation is simple, it gets code from point A => B along with any build time dependencies. If that code has runtime environment requirements (like a global redux store), that's an issue around that runtime environment requirement, in this case Redux. There is no magic in Module Federation that will just magically make this work. "how to proceed"? if your are locked into a global redux store then I would recommend looking up how to asynchronously load connected components and/or reducers. From an architectural standpoint I strongly recommend against connecting Micro-Frontend components to a large global store. MFEs should manage their own state and get/set very little on a global store. IMHO, a massive singleton Redux store has always been architectural mistake.
@@jherr yea thanks for suggestions.... I heard inject reducers and inject saga at run time will that be a good option...???? .i cannot create Central store package since our stores and actions written in individual app so
Would you recommend this for large Saas application? I mean if you are going to have a lot of components, sharing through webpack config feels a bit difficult to manage.
The location of the linkage to the components changes, but there is still an identifiable linkage. But yeah, it does become more interesting, in particular as applications share modules bi-directionally. Which is why we created the Federation Dashboard to visualize the system.
Although the actual remote files get lazy loaded as chunks, it will be nice if we can lazy load remoteEntry.js, instead of having it as a script, as well.
I have been trying this from days. Can someone guide me how to share custom font files and its respected .scss file with @font-face to another module. I am trying to expose that in one module and trying to use it via remote in another module. I followed how fruit is exposed in this video. I am getting cannot resolve module error
CSS is an issue with Module Federation (or any Micro-FE technology). I strongly recommend you try a CSS-in-JS type approach, or you have a shared stylesheet that all host applications share so that the Micro-FEs can depend on the existence of the CSS classes. Feel free to join the Discord server and drop in your questions in the module-federation channel along with some code.
I thought I should come back here to thank you. The styled components suggestion by you, it worked sir. Thank you so much as I get to solve some blocker at work
Lerna, as much as I love it, is still going to deploy every application independently, and so there will be some period of time between when the fast applications deploy and the slow applications deploy when the micro-fes are not in sync. That being said, that may be reasonable depending on your desired SLA.
@@jherr I've been experimenting with it a bit more. Although everything is "published" as a package, when you run the bootstrap command packages get symlinked. That can allow for some good iterative development. But that might be stepping a bit away from the video topic at hand, as I actually do not know how well it bundles with something like webpack. But thank you for the response, really enjoy your insightful videos!
@@MrNathanShow It makes for a great dev environment, that's for sure. We use it at my job in our monorepo, and it's great. It's apples and oranges with Module Federation though, Module Federation is about runtime dependencies between apps in production.
Federation won't take care of making them play well together, but you can definitely share the JS between apps with differing frameworks. You'd just need to handle the work of getting them to work together. I think there is still a space for a micro-fe management framework on top of this. This just makes takes away the module management issues.
You can totally make it work. Of course it's up to you how to bootstrap these different libraries, but with the federated modules you can easily split the core and make it available to your apps. (As the video shows)
@@jherr That's very true. In the end we will still need some sort of orchestrator for applications (which makes total sense), at least now it will be massively lass hacky to share the architectural bits
How do you think guys, If you have MFE implemented with web components, would you share shared store by splitting it with federated modules or would you share it from orchestrator application and attach reference of store to web components ?
TypeScript is an issue with Module Federation since you are sharing compiled JavaScript code. You have to find an out-of-band way to describe the types in the module cleanly to the consuming application.
Getting developers to specify which libraries to share seems like a recipe for unreliability, and certainly not very scalable. I could more imagine a system where Yarn or NPM was aware of the external projects it was going to be federated alongside, and which: 1. Aligned the versions of its common dependencies to maximise re-use potential. 2. Allowed developers to query the list of dependencies that could therefore be shared in common.
There are definitely inherent risks with this. Some of which might be mitigated by putting all the projects into the same monorepo so that they are all on the same versions of the underlying libraries, but still able to independently deploy. You are right though, there are additional layers of multi-project management infrastructure that need to happen to fully realize the potential of this. What I'm happy about is that we are starting to talk about tooling infrastructure for runtime dependencies.
@@jherr, thanks for the reply! Yes, as you point out, monorepos can potentially help here. We use a Yarn based monorepo where I work right now, so we're already in a good position. However, although the first point (aligning common dependencies to maximise re-use potential) is already covered by Yarn Workspaces, the second point (allowing developers to query common dependencies) is not. And, unfortunately, even the `yarn list` command does not show workspace specific dependencies -- if it did then we could use something like the UNIX `comm` command to determine the list of shared dependencies for ourselves. All that being said, the path to how we get there is now at least visible, which is great!
@@footube3 Have you looked at Preconstruct? preconstruct.tools/ It's on my list of things of things to do a tech-a-day on. It's kind of a tooling layer on top on monorepos.
I am looking some help to create an architecture where we can migrate the existing Angular 11 monolith application into small independent self compiled build with the help of moudle federation and load those remote apps on demand at run time. In this migration we want to provide scalabilty and high availability for our end users hence we are thinking to deploy 4 instances of Shell Module and 4 instances of each remote module running on different containers. Whenever end user will try to load our app then with the help of load balancer it will load the available shell module and then shell app will load the remote modules running on different containers. Now the question here is that if we have multiple instances of remote modules which are running on different conatiners then can we put another load balancer between shell module app and remote module app so that we can load remote modules as well as per their availability? It would be really help if somebody has done that in past or interested to do the same with me. Thanks in advance for showing interest on this interesting idea. Thanks Maneesh
It's a runtime dependency. For example, if your app brings in the federated header module from the nav app. Then when the nav app deploys a new version you will get that update instantly. You do not have to re-deploy your site.
Here is the original article - medium.com/swlh/webpack-5-module-federation-a-game-changer-to-javascript-architecture-bcdd30e02669 - It's a Medium article. Normally if you hit it in incognito mode you can push past the paywall.
@@mazimadu Sorry. Unfortunately it's not my article so I can't control the access. Normally Medium gives you a certain number number of article reads per day.
I'm not too worried. Micro-FEs are essentially just client side loaded widgets and we've been doing that since Javascript first launched on the browser. Actually I would say that this trend is getting back to what we had early on in Javascript which was lightweight runtime dependency management. Which when well executed was performant and safe. It's interesting because Webpack launched in 2014 and spurned on the "bundle-era" where we have mega single bundles, or now split bundles. And yes that has some advantages but we lost the ability to do runtime dependencies until now, with Module Federation. So we are just re-opening an architectural door that we closed off completely. We should have left that door slightly open to be used as warranted. Honestly though, when you have a lot of teams working and deploying independently, then the only choice is to use some time of runtime dependency to accomplish the update of shared code that needs to be deployed site wide simultaneously. And this is the most integrated runtime dependency solution I've seen.
@@jherr Well... Why is micro-frontend approach is better then, say, splitting large monolith app into few smaller ones (but self-contained as well), designed for specific audience (users with specific needs within business model)?
@@alex_chugaev Right, so this is exactly what is happening out in the real world. Big e-Commerce company X has a monolith site that takes forever to develop on and deploy. So they make a bunch of smaller applications that can deploy independently; e.g. home, product detail, search, cart, etc. That's great, but all of those applications need to share the header and footer. But... they can't have the case where when the customer goes from page to page to page they can potentially see a different header because home was built with one version, and search was built with another. So they need a runtime dependency with the header so that the header can be its own thing which is independently deployed and versioned. That's a Micro-FE. And that's what Module Federation makes really easy. I've seen a BUNCH of hand-rolled solutions, none of which had this level of quality and support. Now if you are saying that you have a case where you have a monolith with multiple apps in it where they share zero dependencies, or where those shared elements could be shared at build time, then, awesome, you don't need a runtime dependency mechanism like Module Federation. But I've never seen that.
@@jherr I just can't accept such a massive separation. There should be a massive reason to do that. For me, situation when multiple apps have exactly the same header (read navigation) is ridiculous, because in this case it's just a single app where navigation is a clue. Maybe example with Homepage/Product/Search/Cart is not the best? I could agree on separation into HomePage and Shop apps each using appropriate stack. But cutting it deeper doesn't feel right.
@@alex_chugaev So you're saying that because the apps share a header they should not be separated? Or are you positing that there is a different solution that isn't either a monolith or a complete separation? And if so, what would that be and how would it compare with the two other approaches. Fact of the matter is that I've worked at two different Fortune 100 companies that have done the monolith to independently deployed applications shift (neither at my prompting), and consulted with several other companies that have done the same. So this is definitely a situation that does exist.
thanks for this. Webpack's own explanation of this is incomprehensible
So glad you made it fast and straighfoward, wish all the tutorial were this fast paced (without sleep-inducting writing)
Hi Jack,
Thanks for putting out these videos. I wanted to get into the frontend architecture but wasn't able to find the correct path. I think you hold great knowledge. Thanks for sharing it with us.
Wow thank you for the clear explanation, my graduation internship project is about micro-frontends and this will be perfect for one of my use cases, I'm excited to implement it 🥳
It's integrated into the Webpack 5 master now!
I'm gonna be preaching this for a long time. This is quite possibly the coolest thing ever. I really am dying to work on a project like this.
Days without a new JavaScript paradigm: 0
The really good way to describe about Module Federation.
This is mega awesome, the missing piece of the puzzle for my current project :) Thanks for a very good explanation!
thanks Jack, this is what i needed to get it, you making a good job, awesome
Good work. Well done, Jack!
Great content and great explanation Jack!
Awesome explanation, very clear the power of this plugin
Love your stuff Jack really well made video. I'd be up for any paid course you might have in mind!
Amazing video Jack! Exciting times ahead at bigger companies scaling using reusable principles
This is amazing.. cant wait for webpack v5 o/
Thanks for the content!
Hi Jack! This is super cool!
Awesome video, thanks
Im going to subscribe. "This is the way"
Superb quality
That’s pretty cool. Lol 2 years later and I’m just learning about this. I work more in the server-side end of things so…
What are your thoughts about web assembly?
I'm blown away with some of the WASM use that I've seen where they are running node servers in the browser in a WASM context. It's super cool.
@@jherr Wow! That’s crazy.
Awesome well explain
Although this is a very cool way to share code, I am still very skeptical on the governance at the organizational level. If each app is managed by two different teams, doesn't that mean that one team is now managing the dependency of the other? What if the Home app no longer wants to use ProductCarousel? Are they forced to keep the component within the Home codebase even though it's obsolete? Should the ProductCarousel be transferred to another team? Would that force any other teams using ProductCarousel to have to update their code? Why should be the Home app be the owner of this dependency and not the Search app? I have many questions.
It means all of that, but it's not clear to me how that's any different from NPM. The only difference between NPM and MF in this case is that with NPM the code exists in another library, whereas in MF the code exists in the app. From my experience the pain points of jumping back and forth between a library and the consuming application to get a bug fixed is far worse than ownership concerns over an exposed component. Also, at the large organization level the "ownership" of code is a big ongoing concern and not taken lightly. So if team A decides to take on building and owning ProductCarousel long term then it's probably a big part of what they do.
Hi Jack, I´m from Colombia. I have a sentence that I think is correct. Module Federation is a way to share logic or visual components in the front end, that is similar, but no equals, to Microfrontends (MF). When we talk about MF we are talking about isolated applications living together in a container. Each one app is a domain. If you want to share small capabilities, you should use module federations for example, but if you want to share whole app about a buisiness domain, you should use MF strategy. Can you tell me if I am right? Thanks, nice video.
Very cool about Colombia. Let me give my one sentence synopsis: Module Federation is a code transport layer that can be used for Micro-Frontends (as well as many other uses for shared code.)
And then a little extra; Module Federation does not provide a view platform agnostic capability like Single SPA which is required when you want to run MFEs from different view stacks on the same application. For example, a Vue application that hosts a React MFE.
@@jherr thanks so much. I'm more clear about that topic (y)
Thank you Jack for a clear explanation of the subject. However, I have a tricky question. The thing is that I'm a bit worried about dependency re-usage. Right now, it's not clear how exactly this mechanism is working. It looks straightforward when there is no needed dependency found in the host project, the system will load it from the remote.
But how does it works when there is a dependency in both apps, but the version differs? Is there a way to check for version compatibility somehow (using semver?) or will it just load the dependency blindly (and possibly break the app due to a versions missmatch)?
The other question that really worries me is how does it work with tree-shaking? The thing is that each application uses only a subset of the library in question, the other part of the library is just removed from the bundle (consider lodash-es). What will happen if the system would try to use the tree-shaken dependency from the host application and will call a symbol that was removed from the bundle? This looks pretty dangerous, especially considering the fact that the binding happens in runtime and both apps change independently.
Webpack does a really good job with dependency resolution and it gives you a number of rules you can apply to manage the dependency overlaps. On the tree shaking side I'm not sure. The best person to answer questions like that is Tobias Koppers or the Webpack support community.
@@jherr thank you for a quick reply. I guess I will escalate my question regarding the tree-shaking then :)
Considering the dependency resolution in federated apps, is it documented somewhere?
@@slavafomin Yep. You can take a look at a lot of examples here: github.com/module-federation/module-federation-examples And we have a book out on Module Federation: module-federation.myshopify.com/ Also, this particular video is very old. I think this was the first video I did on it and that was pre-alpha. So you may want to look at some later videos in my Module Federation playlist to get a sense of what the released system looks like.
@@jherr that's great, thank you. Do you have maybe a Kindle version of the book? :)
Also, do you consider this technology production ready? Do you know if some serious companies are using it in the wild?
@@slavafomin The Kindle format didn't work well for the book. :( I do know of one big e-Commerce company using it in prod. And is released, maintained, and gradually attracting more and more interested based on book sales which have been steadily increasing.
Thanks for the amazing content!
It's brilliant! Thanks
Great video!
Great video!
I think I understand the concept but what would happen if say a component that is used in another page is modified and breaks the implementation on pages that are dependent on it. Also, as component sharing increases, would the component's author need to be notified that their components are being used elsewhere so some sort of versioning needs to be implemented for the respective component? I guess one page can be designated for sharing so that every component version is retained but then I don't see why that isn't already done with existing monolithic implementations.
Nvm, I watched your versioning video. I still don't get the primary advantage of MF other than not having to update package.json. Feels a lot like deno's remote imports.
Deno still downloads versions for build and run. The big win with MF is that it establishes runtime dependencies. Which are super important in multi-team multi-app situations because there is a need to release some components or code simultaneously across all the applications. And it's runtime dependencies that can get you there.
I can't wait to get my hands dirty with this!!! Thanks
Hi 👋 so, did you try micro-frontends? what's your verdict on this?
Not sure how does this differs from the Bazel. I can already to make hermetic app-shells and reusable widgets and components, which i can throw in wherever i want. To use dynamic imports, reducer injection and other things. Sure, it's mono-repo centric so everything becomes shareable. On top of that i can build Protobuf type declarations and share them between FE and BE with ease. If any single shared piece gets updated, then chain of incremental builds is triggered testing every consumer of that updated lib/component/whatever. Single tool for the all build and deployment requirements for booth, the back-end and front-end.
The only use-case i can see so far is related to local DX. Like.. simplified version of spinning up dev environment locally.
But.. definitely really interested to dig deeper into this. Nice stuff.
Can you send me a link to Bazel? Because the only Bazel I'm seeing is www.bazel.build/ and that seems to be Java (C++, Android, etc.) centric.
@@jherr That is it. No. It's multi-language build system with good TypeScript support, etc. Large Angular projects (and React, etc) are commonly managed with Bazel. It's not the simplest tool for the first day, but... not that complex if you spend some time. I myself found it bit similar to Ansible. :) You can do all the crazy things with it by writing your own rules if you wish. Rules_nodejs and ts_library is a good starting point for the TS projects.
Ouh... one thing... it's mono-repo centric... You can have multiple workspaces, but overall all the code sharing features comes out of this fact.
@@Oswee Oh, interesting. I'd love to see it if you have a repo I can clone and try out. One very big difference would be that Module Federation doesn't require the mono-repo.Most of the examples use them because it's just easier to deal with in a learning context. But in reality you can have different teams, working in different repos, deploy to production independently. Then those teams in turn could use components directly exported from each others applications (not externalized into libraries).
@@jherr I am working on some "boilerplate" setup with Web Components, Redux modules, Protobufs and Go, but it's still in quite messy state. Yeah... poly-repo setups has it's own niceties. I went into Bazel exactly because of Lerna and inability to build Protobuf TS type declarations. I mean... in order to use types in BE and FE i must build and publish every package on every change. Then i should pull them down. Etc. Gets really messy. So... what i found is that Bazel can do all of that for me which from DX point is a great deal. I don't need yarn workspaces, lerna etc. Single tool. Especially important for full-stack polyglot setups. Downside is that it's harder to enforce some "RBAC" for teams. (I'm not in that envirionment). Because of my old habbits i implemented webpack-dev-server into my bazel setup. It works. But... it somewhat feels wrong... So today i went back to research, saw this federation thing, but ... the big picture does not come together anymore. I have some gap in order to understand do i really need webpack at all. All artifacts are build by Bazel. So... what should i use webpack for? Bundling? No... bazel does that. Probably local serving... but... i also start to doubt that. With the same success i can bundle it into Go container and deploy it anywhere (of course with the same tool). Or... make a volume mount directly to the artifacts (lol).
If i would be still in the Lerna & Co world the for sure i would deep dive into Federation. But unfortunatelly now i have more questions than answers. Can't wait tomorrow to keep my research. :)
@@Oswee Cool. Really looking forward to seeing whatever you come up with! I think the difference is that in the e-Commerce environment where I'm normally operating we already have multiple React apps (micro-sites) across multiple repos and all of them are already being webpacked. Within that "micro-site" architecture sharing becomes a huge pain. So Module Federation just adds this extra additional feature of being able to share code much more easily within the context of that setup.
Thanks for the awesome video, I have a question for you. Does this allow for different npm module dependency versions? Let's say the "Home" team needed to use a more recent version of Material UI than the "Search" team. Would they just remove it from the shared array in ModuleFederatedPlugin? My bad if I missed that your video.
That's a good question. I think you are right. I think sharing it implies that you are will to get that dependency from the host if available.
@@jherr That's awesome, really looking forward to webpack 5.
@@StreetDogWrangler Me too!
That is really impressive Jack. Thanks a lot for this.
I have a question:
Would it be possible to use this approach for theming with sass variables?
Example:
- My Bundle contains a bunch of UI Components using sass with some variables set to default values and also imports a "federated (remote) scss file".
- My app uses Bundle1 and provide the remote scss that overrides some of those sass variables
I'm not sure if this is feasible but it would be really cool!
If it's not JS then that's gonna be a problem. So any CSS-in-JS solution, or CSS-in-JS work a like, will work.
This is super helpful! Question not related to the content: how do you make animated boxes as shown eg at 0:35-0:48?
After Effects.
Great thanks for the walkthrough!
One question. I read that federation defaults to what it can find locally. So would this still work in a PWA?
I assume I couldn't use lazy loading as that may cause an issue if the app / site was loaded then went offline before all the modules were loaded.
From a devops perspective Module Federation is just elaborate bundle splitting. Your modules are just JavaScript files that are deployed to static asset stores (e.g. S3). So if S3 goes down before all your assets are loaded, that I guess would be a problem.
Love it. Thx sir
nice 🔥
Thanks 🔥
This is so good!!!!
thank you a lot!
That's is awesome, just touch webpack at right time .
Can you suggest how authentication will work to make it more secure.
Assuming you are using something like React and you are sharing your auth state is context. Then that auth provider can be a federated module itself which is shared by both the host application and any MFEs through traditional context. Or if you are doing the Redux thing you can make it a part of the store.
Thank you, I'll give it a try and will confirm ,once done .
I'm curious how do we use micro-frontends with Module Federations across different repos? Say you have Home and Search on different repos. How would Home leverage code from Search compiled from a separate repo
Mono repo or different repos doesn't really matter. What matters is the deployed location. In the demos I "deploy" to localhost and depend on it from there. But in production you would deploy to an S3 bucket (or equivalent) and depend on that URL.
6:39 Couldn't you put that button in the fallback to avoid implementing custom "shown" logic?
It's been 3 years already but still great content! I have two questions. Is it possible to share other static files besides JS files? I see the fruit images are stored in the home app. How is the search app able to render those images since they're not available locally? Maybe I'm missing something...
They are referenced by URL from the other server, but in production they should be stored in a static asset store, e.g. images.mycompany.com/image.jpg
@@jherr So it wouldn't be able to get the images if the home app server was down, right? But I guess that's just for the demo. In a real-world app the remote exposed files (JS included) would be stored in a static asset store as you've just said. Got it! Thanks!
@@viniciusneto6824 correct. In a correctly deployed real world scenario you would not run into this “it’s down” scenario unless your static asset server fell over (unlikely in the case of S3) or if the assets were errantly removed. Also a CDN is another good option here and also provides a ton of stability.
Thanks for this video! A question that's come up within my organization is around reusing components across CRM apps (think Salesforce implementation) that serve a certain set of personas (think CSRs) and customer facing apps (think Web and Mobile apps that are deployed for self-service by the customer). I presume that that is doable assuming all things being equal - data being presented to the personas. I've not gotten good references around embedding such a micro front end within Salesforce or vice versa. Any pointers appreciated.
Have you ever looked into doing module federation in a serverless environment? It seems like serving up federated parts to consume from a serverless environment would be a good match. But the last time I did any real learning about serverless was 4+ years ago - so maybe I have my head in the clouds... ;-)
Federated Modules are just Javascript files. They should be deployed off of S3 (or equivalent.)
Is this possible to share across react native also
Yeah, repack now supports module federation.
Great voice and content!
Cool!
Hello Mr. Herrington
My micro-projects are exposed on the server and the project they are remote is in my local, my problem is that fonts are not displayed in my local project
Which part do you think has a problem?
Module federation shares JavaScript modules. And that doesn’t include css unless you do css in JS. And I don’t think it can do fonts at all. So you’d need to have the host and remote apps both include the same fonts.
I have a HOST app with angular material 13.1.x, and a remote app with angular material 13.1.y
On import i get "Uncaught SyntaxError: Cannot use 'import.meta' outside a module"
Is there a way to keep updating remote packages and let the host app sit with a lower package version?
Not sure. I don't do a ton with Angular. You might want to check out the folks behind this module: www.npmjs.com/package/@angular-architects/module-federation
Great video! I am curious... What does federation do that something like Lerna can't already do? Lerna can link dependencies locally so I'm trying to see the difference here. Thanks!
Lerna works at build time. So in order to see changes in shared code you'd need to re-deploy any applications that rely on that code. In the federated model, once the application that hosts the code is updated then any applications consuming that code would get the update immediately. (There are inherent risks with this approach. ;) )
Indeed this is my question too. I think solving this at build-time with a monorepo is a much safer strategy. And it makes it more clear where the dependencies are coming from. I'm curious what the real-world use case for this is. A giant company where teams don't speak to each other and work on various repos -- but still want to share code?
How does the coordination between the two servers happen? i.e, when code changes in one app, how is it pushed to the other app automatically?
It's not pushed. The client requests the federated module code, as a JS file, on the next page refresh.
@@jherr I see. I am also wondering if module federation helps in creating a SPA app which has several micro front-ends as separate pages, have some shared components (published in as a separate npm package) and a library like React? Is it possible to name entire packages as shared dependencies in the ModuleFederationPlugin?
@@DK-ox7ze You have to expose modules one by one, unless you want to expose an "index"-style route that has multiple exports. There is also the "shared" key in the configuration that defines the libraries you want to share, and those are shared completely.
Can't stop thinking about how this will integrate with a CI setup? If a component is shared to other applications and is updated, is there any way for the other applications to run their e2e tests and then decide to implement the update or stay on the older version?
On the stability side, you can use a fallback pattern I described in the "resilient header" video (th-cam.com/video/K-yQB9YGmgE/w-d-xo.html). In that video I show how to use a potentially stale npm copy as a backup using error boundaries.
On the CI side, yeah, you are always pushing the `remoteEntry.js` to a well known stable location, and then that `remoteEntry.js` might point to different chunk names on each build.
There is a project called the Module Federation Dashboard which tracks who depends on what federated modules and also allows you to do a rollback if there is an issue in production.
The requirement for E2E testing isn't specific to this approach to Micro-FEs. All runtime dependency systems (OpenComponents, SingleSPA, Module Federation, SingleSPA + Module Federation, etc.) are going to need runtime smoke tests and error monitoring after the deploy.
@@jherr Sorry! I totally forgot to thank you very much for your knowledge sharing and great content! Just had the question in my head and needed to get it down.
@@Norfeldt Oh hey, no worries at all. Totally fine. Thank you for the view, and let me know if there is more content that you would like to see that might help you. I think my most recent video on Micro-FEs Simplified (th-cam.com/video/tFDvEITdJZ8/w-d-xo.html) represents the best I've done on this topic. Though I am doing a Vue version of that coming up that I'm super excited about.
@@jherr Great to hear. I'm personally very interesting in react and testing (as you might have guessed) - I'm finding every excuse/good side projects to play around with cypress (like unit tests, but find the cypress e2e approach very intuitive), so loved that you did some e2e testing with that in one of you federal modules videos .
Just discovered you channel recently and must say I find the content really exciting 🙌👏👍
@@Norfeldt Thanks! All I ask is that you let other people know who might be interested in the content. :) And yeah, I did do the E2E tests in the Full Site Federation video because that's actually a real win for Module Federation. When we went to micro-sites we lost the ability to do a full E2E test before deployment. But MF actually brings that back. You can test updates to one micro-site and use the production code from the other micro-sites and do a complete E2E smoke test through the entire site even across micro-sites. Very cool stuff.
Can we do this purely for server side code? Say a remote app exposes an express middleware and the host app remotely runs the middleware on server side?
Where did you specify the port number of the other applications? I understand that Webpack is exposing certain components from the app's bundle, but how does the consuming code (app) resolve the exposed components?
Through the remoteEntry that it imports from the exposed components project.
@@jherr I see. Could you also explain how code is shared between local webpack bundles (i.e. bundles part of the same app)? Say there are two bundles - bundleA, and bundleB. Both require React, but React is only included in bundleA. So how will bundleB refer React from bundleA?
@@DK-ox7ze As long as react is listed as a shared library between host and remote Webpack handles reusing (and not re-downloading) the react instance. Which is particularly important in that example because react is a singleton and you cannot have two versions of react within the same application.
@@jherr Yeah I understand that React is shared between bundles, but what I meant is, what's the mechanism of this sharing? Given that all of webpack bundle's code is self isolated (as it's encapsulated in an IIFE), how are two bundles able to refer code from other bundles?
@@DK-ox7ze For that you'd need to ask in the Webpack support channels.
I asume that as always webpack is doing here its own magic underneath instead of using web standards like es modules
How did you do the animated diagrams ?
After Effects. :)
Super nice! I love how much effort you've invested to make these videos amazing.
This requires service A to be dependent on Service B up and running always. Isn't MFE hosting better in such cases ?
How to expose component which is connected to redux store and redux saga...??
Just the same way as any other component. Module Federation doesn't manage the environment around your code. It just allows you to share code. You would need to set it up so that the host application provided the appropriate store.
@@jherr I have remote app which is connected to store and middle wares which are already written....now I have to expose this whole app to host basically store is in remote...??i heard in run time we can inject reducers and sagas
But limited docs on that how to proceed??
@@hk_build This is not a Module Federation problem. Module Federation is simple, it gets code from point A => B along with any build time dependencies. If that code has runtime environment requirements (like a global redux store), that's an issue around that runtime environment requirement, in this case Redux. There is no magic in Module Federation that will just magically make this work.
"how to proceed"? if your are locked into a global redux store then I would recommend looking up how to asynchronously load connected components and/or reducers.
From an architectural standpoint I strongly recommend against connecting Micro-Frontend components to a large global store. MFEs should manage their own state and get/set very little on a global store. IMHO, a massive singleton Redux store has always been architectural mistake.
@@jherr yea thanks for suggestions....
I heard inject reducers and inject saga at run time will that be a good option...????
.i cannot create Central store package since our stores and actions written in individual app so
@@hk_build Sounds like a good question for the Redux folks.
Thank you sir
Would you recommend this for large Saas application? I mean if you are going to have a lot of components, sharing through webpack config feels a bit difficult to manage.
The location of the linkage to the components changes, but there is still an identifiable linkage. But yeah, it does become more interesting, in particular as applications share modules bi-directionally. Which is why we created the Federation Dashboard to visualize the system.
Although the actual remote files get lazy loaded as chunks, it will be nice if we can lazy load remoteEntry.js, instead of having it as a script, as well.
Stay tuned. We will next Friday. :)
I have been trying this from days. Can someone guide me how to share custom font files and its respected .scss file with @font-face to another module. I am trying to expose that in one module and trying to use it via remote in another module. I followed how fruit is exposed in this video. I am getting cannot resolve module error
CSS is an issue with Module Federation (or any Micro-FE technology). I strongly recommend you try a CSS-in-JS type approach, or you have a shared stylesheet that all host applications share so that the Micro-FEs can depend on the existence of the CSS classes. Feel free to join the Discord server and drop in your questions in the module-federation channel along with some code.
@@jherr thank you very much sir. You replying means a lot.
I thought I should come back here to thank you. The styled components suggestion by you, it worked sir. Thank you so much as I get to solve some blocker at work
@@srujanashankar9517 Fantastic! Happy to help!
What’s the difference with micro apps ??
What about Lerna?
Lerna, as much as I love it, is still going to deploy every application independently, and so there will be some period of time between when the fast applications deploy and the slow applications deploy when the micro-fes are not in sync. That being said, that may be reasonable depending on your desired SLA.
@@jherr I've been experimenting with it a bit more. Although everything is "published" as a package, when you run the bootstrap command packages get symlinked. That can allow for some good iterative development. But that might be stepping a bit away from the video topic at hand, as I actually do not know how well it bundles with something like webpack. But thank you for the response, really enjoy your insightful videos!
@@MrNathanShow It makes for a great dev environment, that's for sure. We use it at my job in our monorepo, and it's great. It's apples and oranges with Module Federation though, Module Federation is about runtime dependencies between apps in production.
What about multi technology stack ? one of the biggest benefit of MFE is mix technologies. Is it still possible with this new plugin ?
Federation won't take care of making them play well together, but you can definitely share the JS between apps with differing frameworks. You'd just need to handle the work of getting them to work together. I think there is still a space for a micro-fe management framework on top of this. This just makes takes away the module management issues.
It works with any javascript, anything webpack can process, you can federate. React was just convenient here.
You can totally make it work. Of course it's up to you how to bootstrap these different libraries, but with the federated modules you can easily split the core and make it available to your apps. (As the video shows)
@@jherr That's very true. In the end we will still need some sort of orchestrator for applications (which makes total sense), at least now it will be massively lass hacky to share the architectural bits
How do you think guys, If you have MFE implemented with web components, would you share shared store by splitting it with federated modules or would you share it from orchestrator application and attach reference of store to web components ?
It could've been cooler if you had also introduced Typescript.
TypeScript is an issue with Module Federation since you are sharing compiled JavaScript code. You have to find an out-of-band way to describe the types in the module cleanly to the consuming application.
Getting developers to specify which libraries to share seems like a recipe for unreliability, and certainly not very scalable. I could more imagine a system where Yarn or NPM was aware of the external projects it was going to be federated alongside, and which:
1. Aligned the versions of its common dependencies to maximise re-use potential.
2. Allowed developers to query the list of dependencies that could therefore be shared in common.
There are definitely inherent risks with this. Some of which might be mitigated by putting all the projects into the same monorepo so that they are all on the same versions of the underlying libraries, but still able to independently deploy. You are right though, there are additional layers of multi-project management infrastructure that need to happen to fully realize the potential of this. What I'm happy about is that we are starting to talk about tooling infrastructure for runtime dependencies.
@@jherr, thanks for the reply!
Yes, as you point out, monorepos can potentially help here. We use a Yarn based monorepo where I work right now, so we're already in a good position. However, although the first point (aligning common dependencies to maximise re-use potential) is already covered by Yarn Workspaces, the second point (allowing developers to query common dependencies) is not. And, unfortunately, even the `yarn list` command does not show workspace specific dependencies -- if it did then we could use something like the UNIX `comm` command to determine the list of shared dependencies for ourselves.
All that being said, the path to how we get there is now at least visible, which is great!
@@footube3 Have you looked at Preconstruct? preconstruct.tools/ It's on my list of things of things to do a tech-a-day on. It's kind of a tooling layer on top on monorepos.
I am looking some help to create an architecture where we can migrate the existing Angular 11 monolith application into small independent self compiled build with the help of moudle federation and load those remote apps on demand at run time. In this migration we want to provide scalabilty and high availability for our end users hence we are thinking to deploy 4 instances of Shell Module and 4 instances of each remote module running on different containers.
Whenever end user will try to load our app then with the help of load balancer it will load the available shell module and then shell app will load the remote modules running on different containers. Now the question here is that if we have multiple instances of remote modules which are running on different conatiners then can we put another load balancer between shell module app and remote module app so that we can load remote modules as well as per their availability?
It would be really help if somebody has done that in past or interested to do the same with me. Thanks in advance for showing interest on this interesting idea.
Thanks
Maneesh
You should post this question on the #module-federation channel on the Discord server.
I don't get it, how is it better than yarn workspaces?
It's a runtime dependency. For example, if your app brings in the federated header module from the nav app. Then when the nav app deploys a new version you will get that update instantly. You do not have to re-deploy your site.
Pointed to an article I cant access and need to pay for.
-_-
Good job
Here is the original article - medium.com/swlh/webpack-5-module-federation-a-game-changer-to-javascript-architecture-bcdd30e02669 - It's a Medium article. Normally if you hit it in incognito mode you can push past the paywall.
@@jherr On my end they are asking me to upgrade. Im in africa btw
@@mazimadu Sorry. Unfortunately it's not my article so I can't control the access. Normally Medium gives you a certain number number of article reads per day.
@@jherr thanks for the help though. I will check other sources
Is that only me who think micro-frontends is a horrible idea and afraid it become popular?
I'm not too worried. Micro-FEs are essentially just client side loaded widgets and we've been doing that since Javascript first launched on the browser. Actually I would say that this trend is getting back to what we had early on in Javascript which was lightweight runtime dependency management. Which when well executed was performant and safe.
It's interesting because Webpack launched in 2014 and spurned on the "bundle-era" where we have mega single bundles, or now split bundles. And yes that has some advantages but we lost the ability to do runtime dependencies until now, with Module Federation. So we are just re-opening an architectural door that we closed off completely. We should have left that door slightly open to be used as warranted.
Honestly though, when you have a lot of teams working and deploying independently, then the only choice is to use some time of runtime dependency to accomplish the update of shared code that needs to be deployed site wide simultaneously. And this is the most integrated runtime dependency solution I've seen.
@@jherr Well...
Why is micro-frontend approach is better then, say, splitting large monolith app into few smaller ones (but self-contained as well), designed for specific audience (users with specific needs within business model)?
@@alex_chugaev Right, so this is exactly what is happening out in the real world. Big e-Commerce company X has a monolith site that takes forever to develop on and deploy. So they make a bunch of smaller applications that can deploy independently; e.g. home, product detail, search, cart, etc. That's great, but all of those applications need to share the header and footer. But... they can't have the case where when the customer goes from page to page to page they can potentially see a different header because home was built with one version, and search was built with another. So they need a runtime dependency with the header so that the header can be its own thing which is independently deployed and versioned. That's a Micro-FE. And that's what Module Federation makes really easy. I've seen a BUNCH of hand-rolled solutions, none of which had this level of quality and support.
Now if you are saying that you have a case where you have a monolith with multiple apps in it where they share zero dependencies, or where those shared elements could be shared at build time, then, awesome, you don't need a runtime dependency mechanism like Module Federation. But I've never seen that.
@@jherr I just can't accept such a massive separation. There should be a massive reason to do that. For me, situation when multiple apps have exactly the same header (read navigation) is ridiculous, because in this case it's just a single app where navigation is a clue. Maybe example with Homepage/Product/Search/Cart is not the best? I could agree on separation into HomePage and Shop apps each using appropriate stack. But cutting it deeper doesn't feel right.
@@alex_chugaev So you're saying that because the apps share a header they should not be separated? Or are you positing that there is a different solution that isn't either a monolith or a complete separation? And if so, what would that be and how would it compare with the two other approaches.
Fact of the matter is that I've worked at two different Fortune 100 companies that have done the monolith to independently deployed applications shift (neither at my prompting), and consulted with several other companies that have done the same. So this is definitely a situation that does exist.