One key feature of Webpack is removing duplicated code. In the federation environment, host applications serve the remote application with dependencies. In the absence of a sharable dependency, the remote application can download its own automatically. This is a kind of built-in redundancy fail-safe mechanism.

Manually adding vendor code can be tedious at scale but the federation feature allows us to create automation scripts. This is the developer's choice, but it may be an excellent opportunity for you to be able to test your knowledge.

We have already alluded to SSR. You should be aware that server builds require a commonjs library target so that they can be used with Webpack federation. This can be done with S3 streaming, ESI, or by automating npm publish so that you can consume server variants. The following code shows an example of including commonjs:

module.exports = {
 plugins: [
  new ModuleFederationPlugin({
    name: "container",
    library: { type: "commonjs-module" },
    filename: "container.js",
    remotes: {
      containerB: "../1-container-full/container.js"
 },
   shared: ["react"]
  })
 ]
};

You may wish to use the target: "node" method to avoid URLs in favor of file paths. This will allow SSR with the same code base but different configurations when building for Node.js. This will also mean that separate builds will become separate deployments.

Webpack, as a company, is open to demonstrating SSR examples that you, as part of a community of developers, may have made. They will gladly accept pull requests through their GitHub pages since they have the bandwidth to and benefit from the exposure while the process is so new.