Let's take a look at our third and final application:

1. The third application in our system will be exporting a default MainPage. This is done through the following script:

new ModuleFederationPlugin({
   name: "app_three_remote",
   library: { type: "var", name: "app_three_remote" },
   filename: "remoteEntry.js",
   exposes: {
     Button: "./src/Button"
 },
 shared: ["react", "react-dom"]
}),

As expected, the third application looks similar to the previous ones, except it doesn't consume <app> from the first application. This application is standalone and has no navigation and as such, does not specify any remote federated components.

When viewing the system in a browser, you should pay close attention to the network tab. The code can be federated across three different servers (potentially) and three different bundles (naturally).

This component permits a great deal of dynamism in your builds, but you may want to avoid federating the whole application container unless you hope to utilize server-side rendering (SSR) or progressive loading as, otherwise, loading times could be severely harmed.

Loading issues are a natural concern, but one issue that would ordinarily cause larger project sizes is the potential duplication of repetitious code, which is the result of using multiple parallel bundles. Let's take a look at how Webpack 5 handles that issue.