Webpack 5: Module Federation. A Game-changer to Javascript architecture.

Module federation — The Javascript equivalent of what Apollo did with GraphQL. Multiple Webpack builds work together, sharing the dependency graph at runtime. Multiple bundles can share both modules and components from the codebase as well as node_modules. Painless orchestration at runtime. Feels just like a SPA

Until now, a scalable solution to sharing code between independent applications has never been convenient, barley possible. The closest we had was externals or dll plugin, forcing centralized dependency on a external file. It was also a hassle to share code, the separate applications were not truly standalone and usually a limited number of dependencies are shared. Moreover, sharing actual feature code or components between seperately bundled applications is even harder… until now

We need a scalable solution to sharing node modules and feature/application code. It needs to happen at runtime. Externals just doesn’t do an efficient or flexible job. Import maps do not solve the scale problem. I’m not trying to just download code and share dependencies. I’m trying to create an orchestration layer that dynamically shares modules are runtime, with fallbacks and redundancies.

What is Module Federation?

It’s a type of JavaScript architecture I invented and prototyped. Then with the help of my co-creator and the founder of webpack — it was turned into one of the most exciting features in the Webpack 5 core (there’s some cool stuff in there, and the new API is really powerful and clean).

Module federation allows a JavaScript application to dynamically load code from another application — in the process, sharing dependencies, if an application consuming a federated module does not have a dependency needed by the federated code — webpack will download the missing dependency from that federated build origin.