In the previous article of this series, I showed how to use Dynamic Module Federation. This allows us to load micro frontends – or remotes, which is the more general term in Module Federation – not known at compile time. We don’t even need to know the number of remotes upfront.

While the previous article leveraged the router for integrating remotes available, this article shows how to load individual components. The example used for this is a simple plugin-based workflow designer.

The workflow designer acts as a so-called host loading tasks from plugins provided as remotes. Thus, they can be compiled and deployed individually. After starting the workflow designer, it gets a configuration describing the available plugins:

Please note that these plugins are provided via different origins (http://localhost:3000 and http://localhost:3001), and the workflow designer is served from an origin of its own (http://localhost:5000).

As always, the source code can be found in my GitHub account.

Thanks to Zack Jackson and Jack Herrington, who helped me to understand the rater new API for Dynamic Module Federation.

Disclaimer: Module Federation is a brand-new technology that will come with webpack 5. As webpack 5 is currently in beta, it’s not intended for production yet. Also, to make it work with Angular already today, my examples use a patched version of the Angular CLI and a custom webpack configuration. Once webpack 5 is final and the Angular CLI supports it, we won’t need these workarounds anymore but have a more streamlined way for all of this. Nevertheless, investigating this technology already today gives us a sound idea of what’s possible shortly.

Building the Plugins

The plugins are provided via separate Angular applications. For the sake of simplicity, all applications are part of the same monorepo. Their webpack configuration uses Module Federation for exposing the individual plugins as shown in the previous articles of this series:

new ModuleFederationPlugin({
  name: "mfe1",
  library: { type: "var", name: "mfe1" },
  filename: "remoteEntry.js",
  exposes: {
    './Download': './projects/mfe1/src/app/download.component.ts',
    './Upload': './projects/mfe1/src/app/upload.component.ts'
  },
  shared: ["@angular/core", "@angular/common", "@angular/router"]
}),

As also discussed in the previous articles, this configuration assigns the (container) name mfe1 to the remote. It shares the libraries @angular/core, @angular/common, and @angular/router with both, the host (=the workflow designer) and the remotes. Besides, it exposes a remote entry point remoteEntry.js which provides the host with the necessary key data for loading the remote.

#unkategorisiert #angular