Zephyr Cloud Docs
Zephyr Cloud →
Zephyr Cloud →

Micro-Frontends with Zephyr - The Complete Guide

Micro-Frontends' configuration and deployment processes are known to be complicated and painful to debug. Zephyr Cloud not only to helps with resolving dynamic URL and development process for applications applying Micro-Frontends architecture, but also deployment, versioning and more. This section will walk through the necessary configuration to ensure you have a smooth development workflow and deployment process.

Related Documentation:

Checklist

Micro-Frontends Configuration

We have first class support for a Micro-Frontends architecture based on Module Federation. Other Micro-Frontends architectures may already work or will be supported in the future.

An example working shell app's configuration can be seen below as well as in our example repository. For detailed bundler-specific configurations, see our bundler guides.

rspack.config.js
new ModuleFederationPluginV1({
      name: 'app_01',
      filename: 'remoteEntry.js',
      remotes: {
        app_02: 'app_02@http://localhost:3002/remoteEntry.js',
        app_03: 'app_03@http://localhost:3003/remoteEntry.js',
        app_04: 'app_04@http://localhost:3004/remoteEntry.js',
        app_05: 'app_05@http://localhost:3005/remoteEntry.js',
      },
      exposes: {
        './SideNav': './src/SideNav',
        './Page': './src/Page',
      },
      shared: {
        ...deps,
        '@material-ui/core': {
          singleton: true,
        },
        'react-router-dom': {
          singleton: true,
        },
        'react-dom': {
          singleton: true,
        },
        react: {
          singleton: true,
        },
      },
    }),

Build remotes first

At the moment. when we are resolving your remote dependencies, we will need the remote applications to be built first. Be wary that the first built remotes should not be consuming any other remotes.

In the example below where you have one shell and one remote, you will need to build the remote first.

mf_1_circular_dependencies

Let's take a look at another example. You have a shell application, within the shell app you have two modules: HeaderNav and TaskContent.

mf_2_circular_dependencies

The HeaderNav exposes Logo, UserProfileInfo and LeftNav.

The TaskContent exposes SearchBar.

In this scenario, LeftNav is consumed by TaskContent; SearchBar is consumed by HeaderNav.

You will need to build either the TaskContent or the HeaderNav first, comment out the remotes that have yet built and add them back later.

package.json name and Module Federation config

Make sure your remotes' package.json name field is exactly the same as your Module Federation Configurations like so:

package.json
name: 'post'
package.json
// Your first remote's package.json
name: 'follow'
Module
`remotes: ['post', follow']`;

You may refer to Zephyr Dependencies example

Git repository

Several details related to git are required to have a successful deployment.

  • Project directory must be a git repository
  • Current project directory must have a branch
  • Current project must have created a commit

Confirm access right

Do you have the admin or editor access to the application you are trying to deploy? You can check it on Zephyr Dashboard.

If you don't have it yet, you can contact your Admin on Zephyr dashboard to invite you and set up the correct access right. Learn more about Teams & Members.

Related Documentation

Getting Started:

Core Concepts: