{"id":3975,"date":"2020-04-22T22:24:51","date_gmt":"2020-04-22T20:24:51","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=3975"},"modified":"2020-04-22T22:24:51","modified_gmt":"2020-04-22T20:24:51","slug":"the-microfrontend-revolution-module-federation-in-webpack-5","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/the-microfrontend-revolution-module-federation-in-webpack-5\/","title":{"rendered":"The Microfrontend Revolution: Module Federation in Webpack 5"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 1 of 10 in the series “Module Federation”<\/em>\t\t<\/p>\n\t\t\t<\/label>\n\n\t\t\t

\n\t\t\t
    \n\t\t\t\t\t\t\t\t\t
  1. The Microfrontend Revolution: Module Federation in Webpack 5<\/span><\/li>\n\t\t\t\t\t\t\t\t\t
  2. The Microfrontend Revolution: Module Federation with Angular<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  3. Dynamic Module Federation with Angular<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  4. Building A Plugin-based Workflow Designer With Angular and Module Federation<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  5. Getting Out of Version-Mismatch-Hell with Module Federation<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  6. Using Module Federation with (Nx) Monorepos and Angular<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  7. Pitfalls with Module Federation and Angular<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  8. Multi-Framework and -Version Micro Frontends with Module Federation: Your 4 Steps Guide<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  9. Module Federation with Angular’s Standalone Components<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  10. What’s New in our Module Federation Plugin 14.3?<\/a><\/li>\n\t\t\t\t\t\t\t<\/ol>\n\t\t<\/div>\n\t<\/div>\n

    \n 2020-10-13: Updated to use webpack 5
    \n Important:<\/strong> This first part of the article series shows Module Federation with a simple "TypeScript-only example". If you look for an example also using Angular<\/strong>, please     directly jump to the 2nd part of this series<\/a>.\n <\/p><\/blockquote>\n

    The Module Federation integrated in Webpack beginning with version 5 allows the loading of separately compiled program parts. Hence, it finally provides an official solution for the implementation of microfrontends.
    \nUntil now, when implementing microfrontends, you had to dig a little into the bag of tricks. One reason is surely that current build tools and frameworks do not know this concept. Module Federation initiates a change of course here.
    \nIt allows an approach called     Module Federation<\/a> for referencing program parts that are not yet known at compile time. These can be self-compiled microfrontends. In addition, the individual program parts can share libraries with each other, so that the individual bundles do not contain any duplicates.
    \nIn this article, I will show how to use Module Federation using a simple example. The     source code<\/a> can be found here<\/a>.<\/p>\n

    Example<\/h2>\n

    The example used here consists of a shell, which is able to load individual, separately provided microfrontends if required:<\/p>\n

    \"Shell<\/p>\n

    The shell is represented here by the black navigation bar. The micro front end through the framed area shown below. Also, the microfrontend can also be started without a shell<\/p>\n

    \"Microfrontends<\/p>\n

    This is necessary to enable separate development and testing. It can also be advantageous for weaker clients, such as mobile devices, to only have to load the required program part.<\/p>\n

    Concepts of Module Federation<\/h2>\n

    In the past, the implementation of scenarios like the one shown here was difficult, especially since tools like Webpack assume<\/strong> that the entire program code is available when compiling<\/strong>. Lazy loading is possible, but only from areas that were split off during compilation.
    \nWith microfrontend architectures, in particular, one would like to compile and provide the individual program parts separately. In addition, mutual referencing via the respective URL is necessary. Hence, constructs like this would be desirable:<\/p>\n

    import('http:\/\/other-microfrontend');<\/code><\/pre>\n
    Since this is not possible for the reasons mentioned, one had to resort to approaches such as externals<\/a> and manual script loading. Fortunately, this will change with the Federation module in Webpack 5.
    \nThe idea behind it is simple: A so-called host references a remote<\/strong> using a configured name. What this name refers to is not known at compile time<\/strong>:<\/p>\n
    \"The<\/p>\n
    This reference is only resolved at runtime by loading a so-called remote entry point<\/strong>. It is a minimal script<\/strong> that provides the actual external url for such a configured name.<\/p>\n
    Implementation of the Host<\/h2>\n
    The host<\/strong> is a JavaScript application that loads a remote when needed<\/strong>. A dynamic import is used for this.
    \nThe following host loads the component mfe1\/component<\/code> in this way -- mfe1<\/code> is the name of a configured remote and component<\/code> the name of a file (an EcmaScript module) it provides.<\/p>\n
    const rxjs = await import('rxjs');\n\n const container = document.getElementById('container');\n const flightsLink = document.getElementById('flights');\n\n rxjs.fromEvent(flightsLink, 'click').subscribe(async _ => {\n     const module = await import('mfe1\/component');\n     const elm = document.createElement(module.elementName);\n     [\u2026]    \n     container.appendChild(elm);\n });<\/code><\/pre>\n
    Webpack would normally take this reference into account when compiling and split off a separate bundle for it. To prevent this, the ModuleFederationPlugin<\/code> is used:<\/p>\n
    const ModuleFederationPlugin = require("webpack\/lib\/container\/ModuleFederationPlugin");\n\n [\u2026]\n  output: {\n       publicPath: "http:\/\/localhost:5000\/",\n       uniqueName: 'shell',\n       [\u2026]\n  },\n plugins: [\n   new ModuleFederationPlugin({\n     name: "shell",\n     library: { type: "var", name: "shell" },\n     remoteType: "var",\n     remotes: {\n       mfe1: "mfe1"\n     },\n     shared: ["rxjs"]\n   })\n ]<\/code><\/pre>\n
    With its help, the remote mfe1<\/code> (Microfrontend 1) is defined. The configuration shown here maps the internal application name mfe1<\/code> to the same official name. Webpack does not include<\/strong> any import<\/code> that now relates to mfe1<\/code> in the bundles generated at compile time<\/strong>.
    \nLibraries that the host should share with the remotes are mentioned in the shared<\/code> array. In the case shown, this is rxjs<\/code>. This means that the entire application only needs to load this library once. Without this specification, rxjs<\/code> would end up in the bundles of the host as well as those of all remotes.
    \nFor this to work without problems, the host and remote must agree on a common version.
    \nIn addition to the settings for the ModuleFederationPlugin<\/code>, we also need to place some options in the output<\/code> section. The publicPath<\/code> defines the URL under which the application can later be found. This reveals where the individual bundles of the application but also their assets, e.g. pictures or styles, can be found.
    \nThe uniqueName<\/code> is used to represents the host or remote in the generated bundles. By default, webpack uses the name from package.json<\/code> for this. In order to avoid name conflicts when using Monorepos with several applications, it is recommended to set the uniqueName manually.<\/p>\n
    Loading Shared Libraries<\/h2>\n
    For loading shared libraries, we must use dynamic imports<\/strong>:<\/p>\n
    const rxjs = await import('rxjs');<\/code><\/pre>\n
    They are asynchronous and this gives webpack the time necessary to decide upon which version to use and to load it. This is especially important in cases where different remotes and hosts use different versions of the same library. In general, webpack tries to load the highest compatible version. More about negotiating versions and dealing with version mismatches this can be found in a later article of this series.
    \nTo bypass this issue, it's a good idea to load the whole application with dynamic imports in the entry point used. For instance, the Micro Frontend could use a main.ts<\/code><\/code> which looks like this:<\/p>\n
    import('.\/component');<\/code><\/pre>\n
    This gives webpack the time needed for the negotiation and loading the shared libraries when the application starts. Hence, in the rest of the application one can always use static ("traditional") imports like<\/p>\n
    import * as rxjs from 'rxjs';<\/code><\/pre>\n
    Implementation of the Remote<\/h2>\n
    The remote is also a standalone application. In the case considered here, it is based on Web Components:<\/p>\n
    class Microfrontend1 extends HTMLElement {\n\n     constructor() {\n         super();\n         this.attachShadow({ mode: 'open' });\n     }\n\n     async connectedCallback() {\n         this.shadowRoot.innerHTML = [\u2026]<\/code>;\n     }\n }\n\n const elementName = 'microfrontend-one';\n customElements.define(elementName, Microfrontend1);\n\n export { elementName };<\/code><\/pre>\n
    Instead of web components, any JavaScript constructs or components based on frameworks can also be used. In this case, the frameworks can be shared between the remotes and the host as shown.
    \nThe webpack configuration of the remote, which also uses the ` ModuleFederationPlugin '', exports this component with the property exposes under the name component:<\/p>\n
     output: {\n       publicPath: "http:\/\/localhost:3000\/",\n       uniqueName: 'mfe1',\n       [\u2026]\n  },\n  [\u2026]\n  plugins: [\n     new ModuleFederationPlugin({\n       name: "mfe1",\n       library: { type: "var", name: "mfe1" },\n       filename: "remoteEntry.js",\n       exposes: {\n         '.\/component': ".\/mfe1\/component"\n       },\n       shared: ["rxjs"]\n     })\n ]    <\/code><\/pre>\n
    The name component refers to the corresponding file. In addition, this configuration defines the name mfe1<\/code> for the remote. To access the remote, the host uses a path that consists of the two configured names, mfe1<\/code> and component<\/code>. This results in the instruction shown above: <\/p>\n
    import('mfe1\/component')<\/code><\/pre>\n
    However, the host must know the URL at which it finds mfe1<\/code>. The next section shows how this can be accomplished.<\/p>\n
    Connect Host to Remote<\/h2>\n
    To give the host the option to resolve the name mfe1<\/code>, the host must load a remote entry point. This is a script that the ModuleFederationPlugin<\/code> generates when the remote is compiled.
    \nThe name of this script can be found in the filename<\/code> property shown in the previous section. The url of the microfrontend is taken from the publicPath<\/code> property. This means that the url of the remote must already be known when it is compiled. Fortunately, there is already a PR which removed this need.
    \nNow this script is only to be integrated into the host:<\/p>\n
    <script src="http:\/\/localhost:3000\/remoteEntry.js"><\/script><\/code><\/pre>\n
    At runtime it can now be observed that the instruction<\/p>\n
    import('mfe1\/component');<\/code><\/pre>\n
    causes the host to load the remote from its own url (which is localhost:3000<\/code> in our case):<\/p>\n
    \"Laden<\/p>\n
    Conclusion and Outlook<\/h2>\n
    The Module Federation integrated in Webpack beginning with version 5 fills a large gap<\/strong> for microfrentends. Finally, separately compiled and provided program parts can be reloaded and already loaded libraries can be reused.
    \nHowever, the teams involved in developing such applications must manually ensure that the individual parts interact. This also means that you have to define and comply with contracts between the individual microfrontends, but also that you have to agree on a version for each of the shared libraries.<\/p>\n
    What's next? More on Architecture!<\/h2>\n
    So far, we've seen that Module Federation is a strightforward solution for creating Micro Frontends on top of Angular. However, when dealing with it, several additional questions come in mind:<\/p>\n