There are several microfrontend tools / libraries, both open source and commercial, which have been around for a number of years. However, this year some of the functionality that was initially baked into Webpack (Module Federation 1.0) was released as an excellent standalone project (Module Federation 2.0). This extraction enables it to be more widely adopted outside of Webpack and, as we'll discuss, outside of the realm of microfrontends.

Let's discuss how to use it, with some step-by-step code examples.

Webpack Dev Server (Remote)

First, we need an export (class / value) from a remote which we wish to consume from within a host application. Below are a class and a string we'd like to consume from another application:

class TestClass {
  testValue = 'initial value';

  async runTest() {
    console.log('test started');
    await new Promise(resolve => setTimeout(resolve, 1000));
    console.log('test finished');
    return 'test complete';
  }

  getTestValue() {
    return this.testValue;
  }
}

module.exports = TestClass;

module.exports = 'dynamically consumed';

And here is a minimal webpack.config.js which is used to build and run the dev server:

const webpack = require('webpack');
const path = require("path");

module.exports = {
  entry: './src/index.js', // empty entrypoint file
  mode: 'development',
  target: 'async-node',
  output: {
    publicPath: 'auto',
  },
  devServer: {
    static: path.join(__dirname, 'dist'),
    hot: true,
    port: 3002,
    devMiddleware: {
      writeToDisk: true, // force writing files to disk for dev
    },
  }
};

We can then get our dev server running using webpack serve --config webpack.config.js. This doesn't do much of anything at this point, so we'll set up Module Federation next.

First, we need to install the Module Federation packages

npm install @module-federation/enhanced \
            @module-federation/node \
            @module-federation/runtime

Second, we'll use the UniversalFederationPlugin webpack plugin to expose our class and value we defined above.

const { UniversalFederationPlugin } = require('@module-federation/node');
const webpack = require('webpack');
const path = require("path");

module.exports = {
  entry: './src/index.js',
  mode: 'development',
  target: 'async-node',
  output: {
    publicPath: 'auto',
  },
  devServer: {
    static: path.join(__dirname, 'dist'),
    hot: true,
    port: 3002,
    devMiddleware: {
      writeToDisk: true, // Force writing files to disk
    },
  },
  plugins: [
    new UniversalFederationPlugin({
      remoteType: 'script',
      isServer: true,
      name: 'remote',
      useRuntimePlugin: true,
      library: { type: 'commonjs-module' },
      filename: 'remoteEntry.js',
      exposes: {
        './string': './src/expose-string.js',
        './class': './src/expose-class.js',
      },
    }),
  ],
};

Now, when we do a webpack serve, we'll have two exposed components available for our application to consume. Here's what that output looks like:

Dynamic Loading (Host)

Let's work on wiring up the consuming side, which will also need to be built with webpack as the @module-federation/node package we're going to use currently relies on webpack.

const webpack = require('webpack');

module.exports = {
  entry: './src/index.js',
  mode: 'development',
  target: 'async-node',
  externals: [],
  output: {
    library: { type: 'commonjs-module' },
  },
};

Next, we'll breakdown how to create the JavaScript that will consume the remote class / value. This consists of several parts:

• Initialize Module Federation with remotes
• Load the remote components from the initialized remotes
• Watch for changes in the remote
• Reload the remote

First, let's show how to initialize Module Federation. Note that the remote entry here uses the same port that we configured above in the webpack dev server and we've assigned the name 'remote' to this remote.

const { loadRemote, init } = require('@module-federation/runtime');

init({
  name: 'host',
  remotes: [
    {
      name: 'remote',
      entry: 'http://localhost:3002/remoteEntry.js',
    },
  ],
});

We'll then load specific components from the remote, which we exported by name, and then use them.

loadRemote('remote/class').then(async value => {
  loadedClass = value;
  loadedClassInstance = new value();
  loadedClassInstance.getTestValue();
  loadedClassInstance.runTest();
});

loadRemote('remote/string').then(value => {
  var loadedString = value;
});

Now we need to detect when the remote has changes that require a reload. In our case, we're going to poll on an interval to check for changes, as we don't yet have full support for async notification of changes from the remote.

const {performReload, revalidate} = require('@module-federation/node/utils');

setInterval(async () => {
  console.log('host(): checking remote for updates');

  const shouldReload = await revalidate();

  if (shouldReload) {
    // we detected changes and should reload from the remote
    console.log('host(): should reload');
    initAndLoad();
  } else {
    // no changes have been detected
    console.log('host(): should not reload');
  }
}, 5000);

We call initAndLoad() in the above code, which would contain the above initialization, loadRemote() calls, and one more Module Federation call: performReload(). This call is necessary to clear out webpack caches of the remote components we loaded and allow them to be reloaded.

Let's put it all together:

const { loadRemote, init } = require('@module-federation/runtime');
const {performReload, revalidate} = require('@module-federation/node/utils');

let instance;
let loadedString;
let loadedClass;
let loadedClassInstance;

async function initAndLoad() {
  // clear module caches and reset remotes, so we can reload the remotes
  await performReload(true)

  instance = init({
    name: 'host',
    remotes: [
      {
        name: 'remote',
        entry: 'http://localhost:3002/remoteEntry.js',
      },
    ],
  });


  loadRemote('remote/string').then(value => {
    loadedString = value;
  });

  loadRemote('remote/class').then(async value => {
    loadedClass = value;
    loadedClassInstance = new value();

    loadedClassInstance.getTestValue());
    loadedClassInstance.runTest());
  });
}

initAndLoad();

setInterval(async () => {
  console.log('host(): checking remote for updates');

  const shouldReload = await revalidate();

  // do something extra after revalidation
  if (shouldReload) {
    // reload the server
    console.log('host(): should reload');
    initAndLoad();
  } else {
    console.log('host(): should not reload');
  }
}, 5000);

Now, when changes are made to the remote, the host application will detect the changes and reload the necessary bits.

Conclusion

Module Federation has some pretty powerful use cases that extend beyond microfrontends and the browser. There's a lot of potential to leverage it more broadly on the backend to help developers realize some of the powerful features that frontend developers have enjoyed for years.

For a complete runnable example, you can go check out the module-federation-example project, which has both a vanilla JavaScript and TypeScript versions. And if you want to delve further into Module Federation use cases, you can view the quick start docs.

Pluggable Core

We are going to start with a micro kernel style architecture. By itself, the engine will provide little functionality that stands alone, but will instead focus on providing functionality that centers around plugins (e.g. execution, event routing) and facilitating cross cutting concerns (e.g. configuration, container, core logging, HID functionality). Plugins will then provide the bulk of the functionality for a configured setup.

One of the most basic functions that the core needs to perform is the loading plugins. An obvious way for that to be accomplished would be to specify NPM packages to load and then require() them to load their functionality. However, we can make both plugin development and deployment more flexible by not relying on module installation and linking.

We can start with dynamically discovering plugins in configured directories on the local filesystem and this could be done directly, however we're going to introduce another interface layer that will add flexibility to our plugin loading.

Sources

We are going to create a new layer called a "source", which will serve as the bridge between the engine and the plugins it uses. Sources handle the discovery, retrieval, and the loading of plugins. By abstracting sources, the engine remains agnostic of the underlying storage or delivery mechanism.

This allows developers to:

• Seamlessly switch between sources (e.g., local to remote) without changing core engine logic.
• Add new sources, such as cloud-based plugin registries, without disrupting the existing architecture.

Example Sources

1. Local Directory: A folder on the file system where plugins are stored. This is ideal for development or when plugins are managed manually.
2. Network: Plugins hosted on a remote server, similar to a package registry like npm. These are useful for distributing plugins across different environments.

We will start with local plugin directories and eventually extend the system to fetch plugins from other sources (e.g. network), handle different formats (e.g. zip, tgz), support hot reloading (👀) and more.

Sources will have similar life cycles as the plugins themselves (configuration, initialization, startup and shutdown) with the addition of supporting list and fetch operations.

Structure

Let's provide an example structure for a simple plugin, which prints out a log message on an interval. The plugin can be an NPM package with the dependencies it needs and at this point written in any language that can target JavaScript. In this example, our plugin is developed in TypeScript.

We will also include a plugin.json file, which contains metadata for the plugin. This metadata provides the necessary details like the display name, the package name, the class to load, and available configuration options. Later, we'll also be able to surface this information to users of the system in various ways. Here's an example plugin.json:

Our plugin code will need to implement an interface that the core can use to interact with the plugin. Each plugin will implement this interface and allow it to participate in lifecycle events (e.g. receive configuration, initialize, start, stop, receive events).

And here's a really basic example for our HeartbeatPlugin we've described:

Configuration

We want to be able to customize a list of plugins and provide any desired static configuration, which may then be overridden through environment variables. As seen in our sample plugin.json, an option has a name (e.g. heartbeat.interval) which can be referenced in the configuration file and inside the plugin as well as an environment variable the system will override that configuration with. The parsing of those values will be automatically handled and made available to the plugin at runtime.

And once we've configured the relevant plugins to be activated, we want to be able to easily provide an overview of this configuration information directly to users within various interfaces (logs, CLI, web, etc.) This will provide in-stream configuration documentation based on what the plugins themselves expose and how the current environment is configured. We will also want to ensure that some config values can be marked sensitive, so that the values are never printed (e.g. passwords).

Context

To pass around contextual data in threads of work without passing it via functions signatures, we will need to maintain some form of context. Some folks will think of the common use case to maintain request or session data. Key Features of Context Handling include:

• Isolation: Each plugin can maintain its own context while still accessing shared data, ensuring modularity.
• Scoping: Contexts can be global (shared across plugins) or local (specific to a plugin or task).
• Lifecycle Management: The engine creates and cleans up contexts as plugins are initialized or unloaded.

Effective context handling enhances modularity, reduces tight coupling, and ensures the engine and plugins operate cohesively. Maintaining this context data is another critical feature we will want to handle and leverage within the core.

Logging

There are lots of varied needs in logging and we don't want to implement them all, however providing a core logging implementation which has adapters that bridge to specific logging implementations (e.g. winston, pino, log4j, etc.) will prove useful. Implementations can be used directly and the core can be configured to log via the same systems, or one could leverage the logging within the core and swap adapters as logging needs change.

There are a number of features related to logging which we can provide, including: log injectors, log formatting, replacing console.* methods to route via adapters, decorators for grouping, indentation, etc.

Container

Direct code dependencies between components works in many use cases, however sometimes we need to share object instances (e.g. singletons) or integrate some type of IOC / Dependency Injection patterns. Providing a baseline implementation to support these use cases should also be considered.

The system should allow for implementations to leverage existing libraries that are already in common use, and we want to ensure that there is a low barrier to entry.

User Interfaces

Another common need we'll run into is the routing of human interface requests and responses to and from different interactive User Interfaces (e.g. CLI, Web, Desktop). We want to surface data and operations from the system into configured user interfaces.

Examples:

• Dynamically configure our example heartbeat interval at runtime
• Items that require administrative approval (e.g. lossy data changes)
• Expose data from our logging or telemetry plugins

There are a number of common use cases which could be supported through some baseline user interface functionality within the core.

Next

We'll dive into more details on the each of the functionalities we want the core to provide: plugin loading, configuration, logging, user interfaces, containers and more.

This series explores the moving parts of a new "engine" for application development. While the focus is primarily on backend software using JavaScript, it also ties into frontend technologies and polyglot development.

What Are We Building?

An "Engine". But what does this engine do?

We’re building a flexible, modular, and scalable engine designed to be a foundation for a wide range of purpose-built solutions. It provides enough structure to free developers to focus on unique challenges, while limiting unnecessary work and remaining flexible.

What Makes This Engine Different?

This engine is not just another framework — it’s a meta-framework designed to offer a lightweight, extensible foundation on which other frameworks or applications can be built. Here are some of the key principles driving its development:

• Lightweight and Accessible: Simple to adopt and productive from the start, while capable of supporting enterprise-grade solutions.
• Pluggable Architecture: As modular as possible, so that we can leverage existing tech and tailor the engine for specific use cases.
• Security Minded: Plugins execute in secure, isolated environments to ensure stability and safety when possible.
• Polyglot Compatibility: Support for plugins to be written in multiple languages, supporting the integration of best-of-breed tools.
• Testing and Dev Tools: Make testing easy and robust, and do whatever we can to lower friction and boost developer productivity.
• Unified Logging and Observability: Core logging and observability tooling to ensure every aspect of the system is traceable and debuggable.
• Configuration: Robust and integrated handling of configuration and environment variables.
• Service Container: Managing shared implementations and dependencies between components.
• Human Interface Core: Plugins can request user interaction (e.g., CLI prompts, web UI inputs), which the engine routes through pluggable adapters.
• Examples and Documentation: Excellent documentation and examples which demonstrate the functionality of system in different contexts.

Why JavaScript?

While JavaScript's vast ecosystem can sometimes feel fragmented, its ubiquity and flexibility remain unmatched. It enables application development across all layers of the stack—server, browser, desktop, and mobile—and has robust support for native integrations through bridges and WebAssembly. These strengths, combined with its vibrant community, make JavaScript a pragmatic choice for building adaptable, scalable systems.

Next Steps

In the next chapter, we’ll explore the prototype’s architecture, breaking down its components, configuration, and exploring practical examples. I invite you to join this journey, collaborate, and help shape a system that meets real-world needs.