Forem: Zack Jackson

The Future of Module Federation

Zack Jackson — Fri, 25 Aug 2023 23:17:06 +0000

The Future of Module Federation

Over the past 4 years, I have encountered my fair share of limitations in Module Federation. It did the job it was built to do, import code from other bundles. But over time, as use cases, scale, and userbase got larger — there were design oversights that would have been really helpful to consider.

I never expected federation to become as popular as it has, in hindsight there are adjustments that could be made to make it more powerful and helpful. This is something the Infra team saw as well, and they ended up forking the plugin, implementing browser devtools, and addressing many gotchas.

Over the next quarter, we are going to try and separate our internal couplings present in the fork, and instead — implement some aspects directly into Module Federation.

To do so, federation needs to change, in a non breaking manner.
Module Federation Redesign · module-federation/universe · Discussion #1170

Hooks

We deliberately did not add hooks into the plugin as end users would not need or should not tinker around with internal mechanics. I agree with that, but i dont think we considered that we should offer some “framework api”

If federation needs to be modified at all we must either change webpack or fork the whole plugin, ouch. And fork we did in order to integrate it with better management systems and tools.

In version 1.5, we want to introduce hooks so that enhancing federation doesnt require forking the pluign entirely.

Framework APIs

Similar to hooks, in general we need more mid level apis either at build time or runtime. The standard {get,init} api can feel a little too limiting when you're dealing with complex applications. More plugability at runtime and compile time would give framework authors more to work with.

TypeScript Support and Remote Types

There is an increasing emphasis on incorporating robust type systems to enhance code safety and maintainability. Recognizing this need, the next iteration of module federation is set to introduce **built-in **TypeScript support for remote types.

This feature aims to seamlessly integrate remote type definitions, allowing developers to leverage the strong typing capabilities of TypeScript across federated modules.

By doing so, it enhances interoperability, reduces the risk of type-related errors, and fosters a more coherent development experience.

This sets the stage for further innovation in creating more reliable and efficient distributed systems.

Initialization Phases

A major one is the concept of middleware and startup code.

Hosts should be able to apply express-like middleware on the remotes they consume. This would help alot with AB tests, dynamic environment switching, authorization and permissions, error handling and so on.

But, middleware on the consumer end is not always enough or appropriate. Sometimes I may need or want to ship some “startup” code as the author of a remote. Some piece of runtime code that can be executed during the initialization phase of a remote. Like getting environment variables, or ensuring data needed is ready or exists, or inject providers into the application.

Remotes need a way to be able to prepare their consuming environment, if they need to.

Lifecycle

Similar and adjacent to middleware, we we could benefit from a basic lifecycle. Something like a plugin system thats at runtime, that can provide us with more callbacks to react to whats going on.

The middleware implementation provides outlines various hooks that provide opportunities to intervene in the federated module process:

beforeInit & init: Preparing the initial environment and managing configurations.
beforeLoadRemote & loadRemoteMatch: Control over the loading of remote federated modules.
loadRemote: Dynamic control over the loading process of individual federated modules.
errorLoadRemote: Managing errors that occur during the remote loading process.
beforeLoadShare & loadShare: Control over shared modules and their behavior.
beforePreloadRemote: Optimization and control over preload operations.

Middleware:

How should one interact with the middleware flow in an integrated manner?

new ModuleFederationPlugin({
    middleware: './src/federation-middleware.js'
})

//federation-middleware.js

module.exports = {
 beforeInit,
 beforeLoadingRemote,
 loadRemoteMatch,
 loadRemote,
 errorLoadRemote,
 beforeLoadShare,
 beforePreloadRemote
}

At Runtime:

hooks = new PluginSystem({
    beforeInit: new SyncWaterfallHook<{
      userOptions: UserOptions;
      options: Options;
      origin: VmokHost;
    }>('beforeInit'),
    init: new SyncHook<
    [
      {
        options: Options;
        origin: VmokHost;
      },
    ],
    void
    >(),
    beforeLoadRemote: new AsyncWaterfallHook<{
      id: string;
      options: Options;
      origin: VmokHost;
    }>('beforeLoadRemote'),
    loadRemoteMatch: new AsyncWaterfallHook<{
      id: string;
      pkgNameOrAlias: string;
      expose: string;
      remote: RemoteInfo;
      options: Options;
      origin: VmokHost;
    }>('loadRemoteMatch'),
    loadRemote: new AsyncHook<
    [
      {
        id: string;
        expose: string;
        pkgNameOrAlias: string;
        remote: RemoteInfo;
        options: ModuleOptions;
        origin: VmokHost;
        exposeModule: any;
        moduleInstance: Module;
      },
    ],
    void
    >('loadRemote'),
    errorLoadRemote: new AsyncHook<
    [
      {
        id: string;
        error: unknown;
      },
    ],
    void
    >('errorLoadRemote'),
    beforeLoadShare: new AsyncWaterfallHook<{
      pkgName: string;
      shareInfo?: Shared;
      shared: Options['shared'];
      origin: VmokHost;
    }>('beforeLoadShare'),
    loadShare: new AsyncHook<[VmokHost, string, ShareInfos]>(),
    beforePreloadRemote: new AsyncHook<{
      preloadOps: Array<PreloadRemoteArgs>;
      options: Options;
      origin: VmokHost;
    }>(),
  });

Startup

The startup code in Module Federation represents an architectural evolution where remotes have their own lifecycle. This allows nuanced control over the bootstrapping of federated modules, working in tandem with middleware to enable an intricately negotiated 4-way handshake.

new ModuleFederationPlugin({
    startup: './src/federation-startup.js'
})

Examples and Applications

The startup phase incorporates various elements that can be tailored to specific needs:

Environment Configuration: Set up runtime environments for different federated modules.
State Management: Manage global states and inject middleware in state stores.
Real-Time Communication: Manage real-time channels like WebSockets.
Critical Resource Preloading: Preload resources for a smoother user experience.
Error Handling: Handle errors with auto-recovery mechanisms.
Data Integrity: Implement integrity checks on loaded modules.
Access Control: Implement runtime access control.
Theming and Localization: Apply themes or localization settings dynamically.
Cache Management: Manage cache across federated modules.
Integration with Legacy Systems: Integrate with older systems by adapting interfaces.
Custom UI Components Loading: Load or unload UI components dynamically.
Health Monitoring and Reporting: Embed health checks for critical dependencies.
Compliance and Security Enforcement: Ensure compliance with legal or business rules.
Experimentation and A/B Testing: Support dynamic A/B testing without altering the core codebase.
Plug-and-Play Extensibility: Enable third-party developers to extend functionalities.

4-Way Handshake

During the 4-way handshake process, middleware and startup code work collaboratively:

Remote Initialization (Startup): Execution of prescribed startup tasks.
Middleware Execution: Enables the host to perform actions and adapt behavior.
Dependency Linking: Completes the connection and linking in the dependency graph.
Application Execution: Begins executing the application.

Startup Hooks/Lifecycle

Startup hooks focus on the initialization and preparation actions taken by the providers/remotes. They may be the mirror image of the middleware hooks, focusing on provision rather than consumption.

startupHooks = new PluginSystem({
    beforeStartup: new SyncWaterfallHook<{
      moduleOptions: ModuleOptions;
      environment: Environment;
      provider: VmokProvider;
    }>('beforeStartup'),
    onStartup: new SyncHook<
    [
      {
        provider: VmokProvider;
        environment: Environment;
      },
    ],
    void
    >('onStartup'),
    beforeInitializeRemote: new AsyncWaterfallHook<{
      id: string;
      initializationOptions: InitializationOptions;
      provider: VmokProvider;
    }>('beforeInitializeRemote'),
    initializeRemote: new AsyncHook<
    [
      {
        id: string;
        initializationOptions: InitializationOptions;
        provider: VmokProvider;
        remoteInstance: Remote;
      },
    ],
    void
    >('initializeRemote'),
    errorInitializeRemote: new AsyncHook<
    [
      {
        id: string;
        error: unknown;
      },
    ],
    void
    >('errorInitializeRemote'),
    beforePrepareEnvironment: new AsyncWaterfallHook<{
      environment: Environment;
      provider: VmokProvider;
    }>('beforePrepareEnvironment'),
    prepareEnvironment: new AsyncHook<
    [
      {
        environment: Environment;
        provider: VmokProvider;
      },
    ],
    void
    >('prepareEnvironment'),
    beforeFinalizeStartup: new AsyncWaterfallHook<{
      finalizationOptions: FinalizationOptions;
      provider: VmokProvider;
    }>('beforeFinalizeStartup'),
    finalizeStartup: new AsyncHook<
    [
      {
        finalizationOptions: FinalizationOptions;
        provider: VmokProvider;
      },
    ],
    void
    >('finalizeStartup'),
});

Explanation of Startup Hooks

beforeStartup: Allows initial configurations.
onStartup: Core initialization logic.
beforeInitializeRemote: Preprocessing before initializing a remote module.
initializeRemote: Initialization of a remote module.
errorInitializeRemote: Handling errors during initialization.
beforePrepareEnvironment: Actions before environment configuration.
prepareEnvironment: Actual environment setup.
beforeFinalizeStartup: Preprocessing before finalizing the startup.
finalizeStartup: Final actions, including clean-up or validation.

Middleware & Startup as a whole

The integration of middleware and startup code in Module Federation’s architecture marks a significant advancement in handling federated modules. They offer a symmetrical design where middleware focuses on the consumption and host perspective, while startup code targets the provisioning and provider’s view.

Middleware

With various hooks for controlling and customizing different stages of federated module loading and execution, middleware enables a tailored experience for consumers. It provides a granular level of control over aspects such as remote loading, error management, shared module behavior, and preload operations. Middleware allows an intricate alignment with the complex demands of modern distributed systems, offering flexibility, robustness, and efficient handling of federated modules.

Startup

Startup code, on the other hand, introduces a nuanced lifecycle for remotes, focusing on initialization and preparation actions. It emphasizes the provider’s perspective, allowing actions like environment configuration, error handling, integration with legacy systems, cache management, and more. The startup hooks provide a rich lifecycle model that complements the consumption-oriented middleware hooks.

Combined Effect

Together, middleware and startup form a cohesive and comprehensive protocol that caters to both sides of federated module operations. The well-designed hooks and lifecycle phases provide a powerful toolkit for developers to have fine-grained control over the process, from initialization to execution. The 4-way handshake model illustrates how these two components work in unison to ensure a smooth and effective operation.

In essence, the combined power of middleware and startup in Module Federation fosters a more adaptive, resilient, and scalable architecture. It reflects a thoughtful design that anticipates the multifaceted needs of modern development environments, providing the tools and methodologies to create intricate, distributed systems with ease and precision. Whether it’s the flexible customization offered by middleware or the robust initialization provided by startup, this duo forms the backbone of an intelligent system that is poised to revolutionize the way federated modules are handled and executed.

Runtime API / SDK

Middleware, lifecycles, its all related, so is the need for an SDK and better runtime API.

Runtime API should expose the middleware primitives in some way, hookable lifecycles that can be used in react for example.

The SDK on the other hand, aims to take what we are building into the Webpack runtime and turn it inside out.

Federation v1.5 would be more painful to try and support in other build tools, federation already is tricky or “same idea not compatible”. To support other tools, i dont know if their APIs would be worth the effort — its just difficult, federation uses many of Webpacks apis to pull it off so well.

So, instead of maintaining a replica of what Webpack can already do… what if we shipped an empty “webpack runtime”, wrapped its webpack_require exports in a library, and ship it to NPM?

import {createContainer} from '@module-federation/sdk';
const federationConfig = {
  name: 'app2',
  exposes: {
    "./Button": () => {
      return import('./App').then(f => () => f)
    }
  },
  shared: {
    react: {
      version: '18.2.0',
      import: () => import('react').then(f => () => f),
      weakRef: require.resolveWeak('react'),
    },
  'react-dom': {
   version: '18.2.0',
   import: () => import('react-dom').then(f => () => f),
   weakRef: require.resolveWeak('react-dom'),
  }
  }
}

export default createContainer(federationConfig) // => {get,init}

Plugin Hooks

Compile Time Hooks for Module Federation:

This aspect is not fully developed, but the following should offer a window into the direction

Initialization Hooks

beforeCompileInit: Called before initializing the compilation process.

beforeCompileInit: new SyncHook<[InitializationOptions]>('beforeCompileInit'),

“Filesystem” Hooks

customizeFilesystem: Customizing the filesystem for loading chunks or altering the definition of a filesystem during compilation.

customizeFilesystem: new AsyncHook<[FilesystemOptions]>('customizeFilesystem'),

Template Generation Hooks

beforeTemplateGeneration: Preprocessing before generating templates for federated modules.

beforeTemplateGeneration: new AsyncWaterfallHook<[TemplateOptions]>('beforeTemplateGeneration'),

generateTemplate: Generating templates for federated modules during compile time.

generateTemplate: new AsyncHook<[GenerateTemplateOptions]>('generateTemplate'),

API Manipulation Hooks

beforeAPIAlteration: Called before altering or extending the API interfaces.

beforeAPIAlteration: new SyncHook<[APIOptions]>('beforeAPIAlteration'),

alterAPI: Altering or adding more exports onto the main interface.

alterAPI: new AsyncHook<[AlterAPIOptions]>('alterAPI'),

Using (Web|Rs)pack Runtime as a Library? A Possibility

Much of the federation’s value lies in Webpack’s runtime. The idea is to use a “Webpack runtime” to inject dynamic imports into a container-producing factory.

This concept resembles single-spa, where an entry point could be exported from any build as a remote entry or host. The runtime would boot the application, with no need to use Webpack to build it.

Instead of replicating what Webpack does, the idea is to use its pre-built runtime, modify it slightly, and employ Webpack’s actual runtime as a framework. The parent build tool would handle script loading, so the SDK’s responsibilities would be minimal.

Creating a clean SDK with only a Webpack plugin might not be possible, and though it’s not an easy task, it’s preferable to recreating federation with a smaller build API.

As someone who’s worked extensively with Webpack, I’m grateful for having Rspack. It allows flexibility with plugins and has proven more valuable in the long run despite a learning curve.

Difficult architectural or business problems became more manageable or even trivial. With rspack, compatibility is maintained with Webpack, but there’s room for enhancement, and its speed opens new possibilities.

It’s a balance between speed and capability. If rspack can build an 18,000 file codebase in 4 seconds, not 60, it’s fast enough that new powerful capabilities could be introduced without noticeable delays. Doing some of these tasks in Javascript might not be feasible.

Wrapping it up

The evolution of module federation is marked by the development of more refined and specialized APIs. These improvements enable developers to address framework-level challenges, facilitating more nuanced control over the handling of and formation of a distributed system and its module tree.

The introduction of middleware, startup hooks, and compile-time plugin hooks represents a significant step forward. These capabilities allow for a greater range of customization, enriching the architectures scope and utility.

The full potential of these advancements can only be realized within a unified meta-framework that encapsulates the diverse needs of modern development. This is the role that ModernJS aims to fulfill in future iterations. As a platform, it integrates these new features into a coherent whole, providing a practical and efficient approach to building and managing distributed systems.

By giving module federation a “home” within ModernJS, these new capabilities can be leveraged to solve real-world challenges, without losing sight of the underlying technical complexities. This alignment between innovation and practicality forms the foundation for further growth and refinement in the field of micro-frontends and code distribution.
Modern.js
*A Progressive React Framework for modern web development.*modernjs.dev

Rspack 0.3 Release Announcement

Zack Jackson — Fri, 25 Aug 2023 22:49:05 +0000

Since the launch of Rspack 0.2, we've been meticulously gathering community feedback and iterating on our offering. We're thrilled to unveil Rspack 0.3—a significant upgrade that amplifies flexibility, compatibility, and performance. This new release brings a series of breaking changes, major feature rollouts, and finer-grained controls, all aligned to provide you with a more robust, adaptable, and efficient build tool. Read on for a comprehensive look at what Rspack 0.3 has in store.

Breaking Changes

In version 0.3, Rspack aligns the default CSS handling behavior with webpack when set experiments.css = true. This involves removing many built-in CSS transformation logic, which introduces some breaking changes. If your application previously relied on these transformation logic, please pay attention to the migration steps below.

Removal of @rspack/postcss-loader and builtins.postcss

Before Rspack fully supported postcss-loader, Rspack implemented @rspack/postcss-loader and built-in builtins.postcss to fulfill the functionality. Currently, Rspack fully supports postcss-loader, so we have decided to deprecate @rspack/postcss-loader and builtins.postcss. Users of @rspack/postcss-loader can seamlessly migrate to postcss-loader, while users that previously used Rspack’s builtins.postcss for the px2rem conversion functionality can migrate to postcss-loader and postcss-plugin-px2rem. Here is the migration process:

• Before:

module.exports = {
  builtins: {
    postcss: {
      pxtorem: {
        rootValue: 50,
      },
    },
  },
};

• After:

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          {
            loader: 'postcss-loader',
            options: {
              postcssOptions: {
                plugins: [
                  [
                    'postcss-plugin-px2rem',
                    {
                      rootValue: 100,
                    },
                  ],
                ],
              },
            },
          },
        ],
      },
    ],
  },
};

Removal of Built-in CSS Autoprefixer Functionality

To align better with webpack’s CSS handling, Rspack removes the built-in autoprefixer functionality in 0.3. You can use postcss-loader to achieve autoprefixer.

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          {
            loader: 'postcss-loader',
            options: {
              postcssOptions: {
                plugins: [['autoprefixer']],
              },
            },
          },
        ],
        type: 'css',
      },
    ],
  },
};

You can refer to the examples/postcss-loader for a complete example.

Access to Internal Modules Restricted

Due to the current instability of the internal module API in Rspack, directly accessing the internal modules can easily lead to breaking changes. Therefore, Rspack restricts the ability to directly access internal modules and only supports accessing Rspack’s API from the root module.

• Before:

import { Stats } from '@rspack/core/dist/stats'; // not supported since 0.3

• After:

import { Stats } from '@rspack/core';

Major Feature Updates

Web Workers Support

Rspack natively supports Web Workers, which means you can use Web Workers out of the box without using worker-loader. Here is how to use it:

new Worker(new URL('./worker.js', import.meta.url));
new Worker(new URL('./worker.js', import.meta.url), {
  name: 'my-worker',
});

For more information about web workers support, see web workers.

`builtin:swc-loader` Support

Although Rspack provides many SWC compilation configuration options, these configurations are global and cannot fulfill the requirement of using different swc transformation logic for different modules. Therefore, Rspack supports builtin:swc-loader to provide more fine-grained SWC transformation configuration. Compared to the JavaScript version of swc-loader, builtin:swc-loader has better performance. You can use builtin:swc-loader as follows:

const path = require('path');
const config = {
  module: {
    rules: [
      {
        test: /\.jsx$/,
        use: {
          loader: 'builtin:swc-loader',
          options: {
            // Enable source map
            sourceMap: true,
            jsc: {
              parser: {
                syntax: 'ecmascript',
                jsx: true,
              },
              transform: {
                react: {
                  pragma: 'React.createElement',
                  pragmaFrag: 'React.Fragment',
                  throwIfNamespace: true,
                  development: false,
                  useBuiltins: false,
                },
              },
            },
          },
        },
        type: 'javascript/auto',
      },
    ],
  },
};
module.exports = config;

You can refer to examples/builtin-swc-loader for more examples. Currently, builtin:swc-loader still has limitations, such as not supporting wasm plugins, etc. Rspack will continue to iterate and support more features of builtin:swc-loader in future versions.

Improved Profile Support

Performance optimization is a common requirement in business support. To reduce the cost of performance optimization for businesses, we have improved the experience of Rspack Profile. You can generate profile-related files for performance optimization by using the RSPACK_PROFILE environment variable.

$ RSPACK_PROFILE=ALL rspack build

For more detailed information about Profile, see Performance Profiling.

Alignment with More APIs

splitChunks.chunks supports regex.
Supports splitChunk.\{cacheGroup\}.type.
Supports splitChunk.\{cacheGroup\}.idHint.
Supports ensureChunkConditionsPlugin.
rule.use supports functions.
Supports configuration.profile.

More Hook and Plugin Support

Compared to version 0.2, we have implemented more plugin APIs and made compatibility improvements for more plugins in version 0.3. At the same time, we have refined the plugin API support progress of webpack, making the support progress of plugin APIs transparent. You can track the implementation progress of plugin APIs here: plugin-api-progress.

Alignment with Webpack Architecture

In version 0.3, we have further optimized the alignment with the webpack architecture, migrating from the original AST-based codegen architecture to the string transformation-based architecture. This alignment work further ensures that Rspack can align with more Hook APIs of webpack during the codegen stage to be compatible with more community plugins.

Rspack Ecosystem

Starting from version 0.2, Rspack provides support for vue-loader. However, creating a complete Vue.js CLI solution based on vue-loader can be a complex task. To simplify the development of Vue.js applications using Rspack, we offer the Modern.js Builder, which provides an out-of-the-box Vue.js engineering solution called Modern.js Vue.js Support. This solution helps developers easily develop Vue.js applications using Rspack.

Announcing Rspack 0.2

Zack Jackson — Fri, 25 Aug 2023 22:42:56 +0000

Approximately a quarter-year post the unveiling of Rspack 0.1, we've been met with robust community engagement and constructive critique. With the advent of Rspack 0.2, we've augmented our offering with key advancements, including but not limited to, realContentHash for enhanced cache reliability, DataURI for inline asset handling, and native support for the ESM file format. Our technical strides also include strengthened synergies with webpack's API, culminating in full compatibility tests with vue-loader for both Vue3 (version 17) and Vue2 (version 15). We extend an open invitation for you to explore these newly-incorporated features in Rspack 0.2 and are keen to assimilate your expert feedback.

Main feature updates

Loader

Version 0.2 has completed compatibility with most of the loader APIs, including: inline match resource, pitching loader, and inline loader. More APIs have further improved compatibility with webpack loaders, details of which can be found in our webpack compatibility updates Loader API.

Plugin Hooks

New hooks for plugins have been added.

Compiler hooks:

Compilation hooks:

NormalModuleFactory hooks:

ContextModuleFactory hooks:

beforeResolve

realContentHash

We have implemented optimization.realContentHash, which calculates the Hash based on the final product's file content. This makes the generated Hash more stable and is better utilized for caching. In version 0.2, this feature will be enabled by default for production environment builds.

ESM/System format

In the new version, System/ESM products can be generated, and the configuration for outputting ESM products is as follows:

//rspack.config.js
module.exports = {
  // …
  experiments: {
    outputModule: true,
  },
  output: {
    chunkFormat: 'module',
    chunkLoading: 'import',
    library: {
      type: 'module',
    },
  },
};

New `SplitChunksPlugin` implementation

We have restructured the existing implementation of SplitChunksPlugin in Rspack, making the behavior of SplitChunksPlugin more predictable and reducing the cost of troubleshooting related issues.

After the restructuring, we are confident to implement more features on SplitChunksPlugin. We are pleased to announce that in version 0.2, SplitChunksPlugin supports the following configuration options:

splitChunks.maxSize
splitChunks.maxAsyncSize
splitChunks.maxInitialSize
splitChunks.maxAsyncRequests
splitChunks.maxInitialRequests

In version 0.2, we will use the new SplitChunksPlugin by default. If you encounter problems, please provide feedback promptly, and we will fix them as soon as possible. You can switch back to the deprecated implementation by using the experiments.newSplitChunks: false option, but we strongly recommend using the new version. In version 0.3, we will remove the deprecated implementation.

DataURI support

We have implemented support for DataURI. Now you can write the following code to implement virtual modules:

import x from 'data:text/javascript,export default 42';

In addition, we have supported mimetype and scheme as two types of module rule conditions. For example, you can make resources with scheme as 'data' no longer treated as inline processing, but as separate resource files through the following method:

//rspack.config.js
module.exports = {
  module: {
    rules: [
      {
        scheme: 'data',
        type: 'asset/resource',
      },
    ],
  },
};

Breaking Changes

Alignment of Filename Generation Logic

In version 0.1.12, we further aligned the file name generation logic with webpack, and refactored the implementation of file name generation. However, the [ext] in output.filename, output.chunkFilename, output.cssFilename, and output.cssChunkFilename will no longer be replaced. This behavior is now consistent with webpack but is a breaking change for versions of Rspack prior to 0.1.12. If you used [ext] in the above 4 filename configurations, you need to change it to the corresponding .js or .css, for example:

  module.exports = {
    output: {
  -    filename: "[name][ext]",
  +    filename: "[name].js",

  -    chunkFilename: "async/[name][ext]",
  +    chunkFilename: "async/[name].js",

  -    cssFilename: "[name][ext]",
  +    cssFilename: "[name].css",

  -    cssChunkFilename: "async/[name][ext]",
  +    cssChunkFilename: "async/[name].css",
    }
  }

Details: https://github.com/web-infra-dev/rspack/issues/3270

Enabled realContentHash by default in production

Details: https://github.com/web-infra-dev/rspack/pull/3338

Modified the Extensions of Resolve

Details: https://github.com/web-infra-dev/rspack/pull/3242

Modified the Export Method of @rspack/dev-middleware and @rspack/html-plugin, and Removed getRspackMemoryAssets Exported by @rspack/dev-middleware

Details: https://github.com/web-infra-dev/rspack/pull/3358

Webpack Compatibility Updates

As we support more webpack APIs, we are also compatible with more community plugins and loaders. We have adapted some plugins and loaders that have a high demand in the community.

fork-ts-checker-webpack-plugin

Type checking in TypeScript for Rspack is highly demanded. Rspack has fully adapted fork-ts-checker-webpack-plugin. You can use this plugin to perform TypeScript type checking during compilation. However, as TypeScript's type checking is usually very time-consuming, this makes the time required for type checking on larger projects may far exceed the build time of Rspack itself. In dev mode, this plugin will not block the build, but in build mode, this plugin will block the build. Please choose whether to enable this plugin based on your actual needs.

license-webpack-plugin

A widely reported community demand is support for extracting licenses from code. Now, Rspack can achieve the requirement of extracting licenses from the code through license-webpack-plugin.

style-loader & css-loader

Although Rspack supports and enables the experiments.css feature of webpack by default, there are still many communities that strongly depend on style-loader & css-loader. We have completed support for style-loader and css-loader in 0.2.0, which also allows us to better adapt to frameworks such as Svelte and Vue.

node-loader

When using Rspack to package Node applications like Nestjs, a common requirement is to package libraries containing addons. These libraries' native dependencies cannot be directly packaged into js, so they need special treatment. Rspack has adapted node-loader, so you can now use Rspack to build node applications.

Rspack has additional adaptation of webpack's plugins. We have tracked the adapted plugins and loaders in loader-compat and plugin-compat. If you find that a community plugin or loader you are using is also compatible, welcome to submit it to us so we can list it in our compatibility matrix.

Framework Ecosystem Updates

Modern.js Framework

Thanks to the close collaboration and parallel iteration of the Modern.js framework and Rspack, Modern.js Rspack mode has covered 85% of the framework's capabilities, supporting SSR, BFF, micro front-end scenarios, and aligning with TypeScript type checking, code compatibility detection and other features.

At ByteDance, more than 80 projects are using the Modern.js Rspack mode. Some of the projects have been deployed into production and have seen a 10x improvement in build performance.

Modern.js Doc

In addition to the Modern.js framework, the document site solution under the Modern.js system - Modern.js Doc - has also switched the bundler from webpack to Rspack, and rewritten the MDX compilation process based on Rust.

Compared to previous versions using webpack, the current version's build speed can be reduced to seconds. Using the Modern.js official website documentation as an example, the project's startup and build time has been reduced from 30 seconds to less than 2 seconds. In the future, we plan to rename Modern.js Doc to Rspress as the official documentation site solution for Rspack and maintain it through a separate repository.

Welcome to visit the Modern.js code repository and experience the above content.

Vue

Rspack 0.2 has achieved compatibility with vue-loader! For Vue3 projects, you can use Rspack's native CSS and TS processors to improve the compilation speed of Vue projects. All you need to do is upgrade vue-loader to version 17.2.2 or above and set experimentalInlineMatchResource: true. For more information on Vue3/Vue2 support, please refer to guide-vue.

Svelte

Thanks to Rspack's excellent support for the Loader API and the excellent design of svelte-loader, Rspack has fully adapted svelte-loader. Therefore, you can directly use svelte-loader in Rspack for svelte application development. You can refer to example-svelte to complete the svelte-loader related configuration.

Storybook

With the help of the Storybook team, Rspack has completed support for the Storybook React version. You can follow the migrate Storybook method to migrate from the webpack version to the Rspack version. In actual projects, tests have shown that the Rspack version is 5-10 times faster than the Webpack version when the docgen feature is not turned on. When docgen is turned on, since Rspack still relies on babel to handle docgen, the performance is affected, but there is still a 2-3 times improvement.

Angular

With the help of the Valor team, Rspack has completed preliminary support for Angular. You can use Rspack to build Angular applications, but the support for dev and HMR has not yet been fully adapted. We will continue to follow up on Angular support in version 0.2.x.

NestJS

With the help of Rosa, Nx, and Valor, Rspack has completed the compilation support for NestJS. You can use Rspack to package NestJS applications, and in actual projects, tests have shown that Rspack has a 5-10 times build performance improvement compared to the webpack version.

Benchmark

Added a benchmark comparison with esbuild. Please refer to the following link for more details: https://github.com/web-infra-dev/performance-compare

Dev guide

The Rspack team cherishes the valuable contributions made by the open source community and wants to actively fosters collaboration. We are committed to maintaining an open approach, striving to engage and involve the community at every step.

This is why we are currently crafting a comprehensive development guide that equips contributors with all the essential materials required to facilitate the development of Rspack.

The current version of the guide contains all the necessary materials for building, testing, debugging, and profiling Rspack. Additionally, it includes contribution procedures, such as creating a minimal reproducible example.
In the future, the guide will offer an insightful overview of Rspack's architecture, enabling contributors to gain a profound understanding of the project's intricate inner workings.

Test infrastructures

In order to ship with confidence, we are currently:

Building and testing a list of examples in the Rspack repository (currently 38 examples)
Porting all webpack tests from the webpack repository
Running all tests on Node 14, 16 and 18
Maintaining a separate ecosystem-ci repository for integration tests

Nightly Release

In order to expedite iteration, Rspack is released daily with the "@nightly" tag to npm.

Acknowledgements

With the release of Rspack 0.2, we wholeheartedly thank all the contributors who have put effort into this version.

Special thanks to:

@TheLarkInn and @alexander-akait, for answering and resolving many of Rspack team's questions about Webpack.
@zackarychapple, @valorkin, @edusperoni, and @Coly101 for assisting the Rspack team with basic support for Angular and @zackarychapple for reviewing this release blog.
@suxin2017, for supporting System.js format and optional-dependency functionality in Rspack, as well as contributing a lot in terms of Windows compatibility.
@faga295, for supporting the decompression code comment feature and rspack preview feature in Rspack.
@lippzhang, for making numerous contributions in aligning Rspack's behavior with Webpack.
@HerringtonDarkholme, for allowing Rspack to use rspack.config.ts as a configuration file.
@dhruvkelawala, for implementing the builtins.provide feature in Rspack.
@magic-akari, for supporting the new URL("./foo", import.meta.url) syntax in Rspack.
@tuchg, for supporting the packing of .wasm files in Rspack.

We also want to thank all the users of Rspack, for showing trust in such a young open-source project. Your valuable feedback plays a key role in our project improvements and optimizations. Your support and trust is our motivation to move forward.

Finally, let us collectively celebrate the release of Rspack 0.2 and look forward to future developments and more opportunities for collaboration. Thanks again to all friends who support and pay attention to Rspack!

Bundler Design: A Comprehensive Exploration of Modern Bundling Technologies and Techniques

Zack Jackson — Fri, 25 Aug 2023 22:23:18 +0000

Lynx, our company’s (ByteDance) self-developed cross-platform framework (similar to React Native), has a compilation tool that diverges significantly from traditional web compilation tool chains. Unlike conventional tools, it doesn’t support dynamic styles or scripts, essentially eliminating bundleless and code splitting. The module system relies on JSON instead of JS, and there’s no browsing server environment.

Given the need for real-time compilation on the web (build system), dynamic compilation (WebIDE), server-side compilation and delivery, and multi-version switching, we were compelled to create a universal bundler. This bundler had to be flexible, customizable, and operable both locally and in the browser. During its development, we faced several challenges but ultimately succeeded in creating a new universal bundler based on esbuild, resolving most of the issues we encountered.

Update: Since the writing of this article, we have released rspack. The information however is valuable, while not necessarily up to date. I have pulled translated and republished it in english, because I believe that its a great in depth read

Rust Port of Webpack: Rspack | Medium

Zack Jackson ・ Aug 24, 2023 ・
scriptedalchemy.Medium

*Note: The original article is in Chinese, authored by @hardfist

What is a Bundler?

A bundler’s task is to package a series of codes organized by modules into one or more files. Common bundlers include webpack, rollup, esbuild, etc. While most of these refer to the JS-based module system, they don’t exclude other organizational forms (e.g., wasm, usingComponents of JSON for applets, import of CSS and HTML). The generated files might also vary, such as multiple JS files created by code splitting or different JS, CSS, HTML files.

Most bundlers share similar core working principles, but they may emphasize specific functions. Here’s a brief overview:

Webpack: Known for supporting web development, especially with built-in HMR support. It has a robust plugin system and excellent compatibility with various module systems (amd, cjs, umd, esm, etc.). However, this compatibility can be a double-edged sword, leading to webpack-oriented programming. Its rich ecosystem is a plus, but it’s criticized for not being clean enough, lacking support for esm format generation, and being unsuitable for library development.
Rollup: Focused on library development, it’s based on the ESM module system and offers strong support for tree shaking. The product is clean and supports multiple output formats, making it suitable for library development. However, it has some drawbacks, such as needing to rely on plugins for cjs support, requiring more hacks, lacking HMR support, and depending on various plugins for application development.
Esbuild: Praised for its performance, esbuild offers built-in support for CSS, images, React, TypeScript, etc., and boasts an incredibly fast compilation speed (100 times faster than webpack and rollup). Its main disadvantage is a relatively simple plugin system and an ecosystem that’s not as mature as webpack and rollup.
Rspack: Webpacks API rewritten in rust, but this was only after the writing of this post.

How bundlers work

The implementation of bundler is very similar to the implementation of most compilers, and it also adopts a three-stage design. We can compare it

llvm: Compile each language into LLVM IR through the front end of the compiler, then perform various optimizations based on LLVM IR, and then generate different cpu instruction set codes based on the optimized LLVM IR according to different processor architectures.
bundler: Compile each module into a module graph first, then perform optimizations such as tree shaking & code spliting & minify based on the module graph, and finally generate js code in different formats from the optimized module graph according to the specified format.

Comparison of LLVM and Bundler

The similarities between traditional LLVM and bundlers allow many compilation optimization strategies to be applied in bundlers. Esbuild exemplifies this approach taken to the extreme. To understand how a bundler works, we’ll use rollup as an example, given its streamlined functions and structure. The bundle process of rollup is divided into two steps: rollup and generate, corresponding to the bundler front-end and back-end respectively.

Example: Rollup Process

Generating the Module Graph

//src/main.js
import lib from './lib';
console.log('lib:', lib);
//src/lib.js
const answer = 42;
export default answer;

Generating the Module Graph

const rollup = require('rollup');
const util = require('util');
async function main() {
  const bundle = await rollup.rollup({
    input: ['./src/index.js'],
  });
  console.log(util.inspect(bundle.cache.modules, { colors: true, depth: null }));
}
main();

Output

[
  {
    code: 'const answer = 42;\nexport default answer;\n',
    ast: xxx,
    dependencies: [],
    id: 'Users/admin/github/neo/examples/rollup-demo/src/lib.js'
    ...
  },
  {
    ast: xxx,
    code: 'import lib from './lib';\n\nconsole.log('lib:', lib);\n',
    dependencies: [ '/Users/admin/github/neo/examples/rollup-demo/src/lib.js' ]
    id: '/Users/admin/github/neo/examples/rollup-demo/src/index.js',
    ...
  }
]

This output represents the parsed AST structure of each module included in the generated product, as well as the dependencies between modules. After building the module graph, rollup can continue to build products based on the module graph according to the user’s configuration.

Generating the Content

const result = await bundle.generate({
  format: 'cjs',
});
console.log('result:', result);

Generated Content

exports: [],
facadeModuleId: '/Users/admin/github/neo/examples/rollup-demo/src/index.js',
isDynamicEntry: false,
isEntry: true,
type: 'chunk',
code: "'use strict';\n\nconst answer = 42;\n\nconsole.log('lib:', answer);\n",
dynamicImports: [],
fileName: 'index.js',

Plugin System:

Most bundlers offer a plug-in system to allow users to customize the bundler’s logic. For example, rollup’s plug-in system is divided into input and output plug-ins. The input plug-in corresponds to generating the Module Graph, while the output plug-in corresponds to generating the product according to the Module Graph. Here, we’ll focus on the input plug-in, the core of the bundler plug-in system, using esbuild as an example.

Core Hooks of Input Plug-in Systems

onResolve: Determines the actual module address based on a module ID.
onLoad: Loads module content according to the module address.

Esbuild and rollup differ from webpack in that esbuild only provides load hooks, and you can perform transform work within these hooks. Rollup additionally provides transform hooks, while webpack delegates transform work to the loader.

Esbuild Plug-in System

The esbuild plug-in system’s most distinctive feature is support for virtual modules. Here are some examples to demonstrate the role of the plugin:

Example 1: Loader

A common requirement in webpack is to use various loaders to process non-JS resources. Here’s how to use the esbuild plugin to implement a simple less-loader:

export const less = (): Plugin => {
  return {
    name: 'less',
    setup(build) {
      build.onLoad({ filter: /.less$/ }, async (args) => {
        const content = await fs.promises.readFile(args.path);
        const result = await render(content.toString());
        return {
          contents: result.css,
          loader: 'css',
        };
      });
    },
  };
};

Example 2: Sourcemap, Cache, and Error Handling

A more mature plug-in must consider sourcemap mapping after transformation, custom cache to reduce repeated overhead, and error handling. Here’s an example using svelte:

let sveltePlugin = {
  name: 'svelte',
  setup(build) {
    let svelte = require('svelte/compiler')
    let path = require('path')
    let fs = require('fs')
    let cache = new LRUCache(); // 使用一个LRUcache来避免watch过程中内存一直上涨
    build.onLoad({ filter: /.svelte$/ }, async (args) => {
      let value = cache.get(args.path); // 使用path作为key
      let input = await fs.promises.readFile(args.path, 'utf8');
      if(value && value.input === input){
         return value // 缓存命中，跳过后续transform逻辑，节省性能
      }
      // This converts a message in Svelte's format to esbuild's format
      let convertMessage = ({ message, start, end }) => {
        let location
        if (start && end) {
          let lineText = source.split(/\r\n|\r|\n/g)[start.line - 1]
          let lineEnd = start.line === end.line ? end.column : lineText.length
          location = {
            file: filename,
            line: start.line,
            column: start.column,
            length: lineEnd - start.column,
            lineText,
          }
        }
        return { text: message, location }
      }

      // Load the file from the file system
      let source = await fs.promises.readFile(args.path, 'utf8')
      let filename = path.relative(process.cwd(), args.path)

      // Convert Svelte syntax to JavaScript
      try {
        let { js, warnings } = svelte.compile(source, { filename })
        let contents = js.code + `//# sourceMappingURL=` + js.map.toUrl() // 返回sourcemap，esbuild会自动将整个链路的sourcemap进行merge
        return { contents, warnings: warnings.map(convertMessage) } // 将warning和errors上报给esbuild，经esbuild再上报给业务方
      } catch (e) {
        return { errors: [convertMessage(e)] }
      }
    })
  }
}

require('esbuild').build({
  entryPoints: ['app.js'],
  bundle: true,
  outfile: 'out.js',
  plugins: [sveltePlugin],
}).catch(() => process.exit(1))

Virtual Module

The esbuild plugin system’s support for virtual modules represents a significant advancement over rollup. Generally, a bundler needs to process two types of modules: those whose paths correspond to real disk file paths, and those whose paths don’t correspond to real ones. The latter, known as virtual modules, generate content based on the path form. Virtual modules have a wide range of applications.

Example: Glob Import

A common scenario is when developing a REPL like rollupjs.org/repl/, where code samples are loaded into memfs and then built based on memfs in the browser. If there are many files involved, importing them one by one can be cumbersome. Support for glob import can simplify this process.

File Structure


examples
 index.html
 index.tsx
 index.css

Code

import examples from ‘glob:./examples/**/*’;
import {vol} from ‘memfs’;
vol.fromJson(examples,’/’); // Mount the local examples directory to memfs

This functionality can be achieved by tools like vite or babel-plugin-macro. Here’s how esbuild can implement it:

Analyze Custom Path in onResolve: Pass the metadata to onLoad through pluginData and path, and customize a namespace to prevent normal file load logic from loading the returned path.
Get Metadata in onLoad: Customize the logic of loading and generating data according to the metadata, and hand over the generated content to esbuild’s built-in loader for processing.

Code Implementation


const globReg = /^glob:/;
export const pluginGlob = (): Plugin => {
  return {
    name: 'glob',
    setup(build) {
      build.onResolve({ filter: globReg }, (args) => {
        return {
          path: path.resolve(args.resolveDir, args.path.replace(globReg, '')),
          namespace: 'glob',
          pluginData: {
            resolveDir: args.resolveDir,
          },
        };
      });
      build.onLoad({ filter: /.*/, namespace: 'glob' }, async (args) => {
        const matchPath: string[] = await new Promise((resolve, reject) => {
          glob(
            args.path,
            {
              cwd: args.pluginData.resolveDir,
            },
            (err, data) => {
              if (err) {
                reject(err);
              } else {
                resolve(data);
              }
            }
          );
        });
        const result: Record<string, string> = {};
        await Promise.all(
          matchPath.map(async (x) => {
            const contents = await fs.promises.readFile(x);
            result[path.basename(x)] = contents.toString();
          })
        );
        return {
          contents: JSON.stringify(result),
          loader: 'json',
        };
      });
    },
  };
};

The filtering based on filter and namespace in esbuild is for performance considerations.

The virtual module can not only obtain content from the disk but also calculate content directly in memory, and even import the module as a function call.

Memory Virtual Module

The virtual module concept in esbuild is not only powerful but also highly flexible, allowing for various innovative applications.

1. Environment Variables as Virtual Module

You can create a virtual module that represents the environment variables of the system. Here’s an example:

let envPlugin = {
  name: 'env',
  setup(build) {
    // Intercept import paths called "env" so esbuild doesn't attempt
    // to map them to a file system location. Tag them with the "env-ns"
    // namespace to reserve them for this plugin.
    build.onResolve({ filter: /^env$/ }, args => ({
      path: args.path,
      namespace: 'env-ns',
    }))

    // Load paths tagged with the "env-ns" namespace and behave as if
    // they point to a JSON file containing the environment variables.
    build.onLoad({ filter: /.*/, namespace: 'env-ns' }, () => ({
      contents: JSON.stringify(process.env),
      loader: 'json',
    }))
  },
}

// 
import { NODE_ENV } from 'env'

2. Function Virtual Module

You can use the module name as a function, complete compile-time calculations, and even support recursive function calls. This example demonstrates a Fibonacci sequence:

 build.onResolve({ filter: /^fib((\d+))/ }, args => {
            return { path: args.path, namespace: 'fib' }
   })
  build.onLoad({ filter: /^fib((\d+))/, namespace: 'fib' }, args => {
        let match = /^fib((\d+))/.exec(args.path), n = +match[1]
        let contents = n < 2 ? `export default ${n}` : `
              import n1 from 'fib(${n - 1}) ${args.path}'
              import n2 from 'fib(${n - 2}) ${args.path}'
              export default n1 + n2`
         return { contents }
  })



import fib5 from 'fib(5)'

3. Stream Import

You can run development without downloading node_modules, similar to the streaming import scene of Deno and Snowpack:

import { Plugin } from 'esbuild';
import { fetchPkg } from './http';
export const UnpkgNamepsace = 'unpkg';
export const UnpkgHost = 'https://unpkg.com/';
export const pluginUnpkg = (): Plugin => {
  const cache: Record<string, { url: string; content: string }> = {};
  return {
    name: 'unpkg',
    setup(build) {
      build.onLoad({ namespace: UnpkgNamepsace, filter: /.*/ }, async (args) => {
        const pathUrl = new URL(args.path, args.pluginData.parentUrl).toString();
        let value = cache[pathUrl];
        if (!value) {
          value = await fetchPkg(pathUrl);
        }
        cache[pathUrl] = value;
        return {
          contents: value.content,
          pluginData: {
            parentUrl: value.url,
          },
        };
      });
      build.onResolve({ namespace: UnpkgNamepsace, filter: /.*/ }, async (args) => {
        return {
          namespace: UnpkgNamepsace,
          path: args.path,
          pluginData: args.pluginData,
        };
      });
    },
  };
};

// in file
import react from 'react';

Scenarios and Flexibility

The virtual module allows for different scenarios:

Local Development: Completely use local file loading.
Local Development without Node Modules: Suitable for super-large monorepo projects where installing all node_modules is too slow.
Web-Side Real-Time Compilation: For performance and network issues, where third-party libraries are fixed, and business code may change.
Dynamic Compilation on the Web Side: Intranet WebIDE scenarios, where both third-party libraries and business code are not fixed.

Converting CommonJS (CJS) to ECMAScript Modules (ESM)

On the browser, has been a complex task. While rollup offers a solution, it comes with inherent problems and additional complexities. Esbuild provides an alternative approach, utilizing a module wrapper similar to Node for CJS compatibility, and introducing a minimal runtime to support CJS. This method ensures better compatibility with CJS, simplifies the process by eliminating the need for additional plugins, and represents a promising direction for those seeking to perform this conversion on the browser without unnecessary complications.

Virtual Module Support in Rollup

The support of rollup’s virtual module is quite hacky, and a ‘\0’ is put in front of the dependency path, which is intrusive to the path, and is not very friendly to some ffi scenarios (c++ string regards ‘\0’ as a terminal symbol). When dealing with more complex virtual module scenarios, the path ‘\0’ is very easy to deal with problems.

File System

The local bundler accesses the local file system, but there is no local file system in the browser, so how to access files can generally be realized by implementing the bundler as independent of the specific fs, and all file access is configurable fs to access. Rollup’s REPL(https://rollupjs.org/repl/) does that. Therefore, we only need to replace the loading logic of the module from fs with the memfs on the browser. The onLoad hooks can be used to replace the reading logic of the file.

Node Module Resolution

When we switch file access to memfs, an ensuing problem is how to obtain the actual path format corresponding to the id of require and import. The algorithm for mapping an id to a real file address in node is module resolution. This algorithm’s implementation is more complex and needs to consider the following situations. For detailed algorithms, see https://tech.bytedance.net/articles/69/

file|index|directory three situations
js, json, addon multi-file suffix
The difference between esm and cjs loader
main field processing
Conditional exports processing
exports subpath
NODE_PATH processing
recursive lookup
Symlink processing

In addition to the complexity of node module resolution itself, we may also need to consider the main module filed fallback, alias support, ts and other suffix support and other functions that webpack supports but are more popular in the community, yarn|pnpm|npm and other package management tools are compatible and other issues. It is costly to implement this set of algorithms from scratch, and the module resolution algorithm of node has been updated. The enhanced-resolve module of webpack basically realizes the above functions, and supports custom fs, which can be easily transplanted to memfs.

Main Field

The main field is also a relatively complicated problem, mainly because there is no unified specification, and the community library does not fully comply with the specification, which mainly involves the distribution of packages, except that the main field is officially supported by nodejs, module, browser, browser Various bundlers and third-party community libraries have not reached a consensus on fields such as

How to configure the entry of cjs and esm, esnext and es5, node and browser, dev and prod
The code in module| main should be es5 or esnext (determines whether the code in node_module needs to use transformer)
Should the code in the module point to the implementation of the browser or the implementation of the node (determines the node bundler and the priority of main and module in the case of browser bundler)
How to distribute and process the difference code between node and browser, etc.

Upkg

Next, we need to process the module of node_modules. There are two ways at this time. One is to mount the full amount of node_modules into memfs, and then use enhanced-resolve to load the corresponding modules in memfs. The other way is to use For unpkg, convert the id of node_modules to unpkg’s request. These two methods have their applicable scenarios. The first one is suitable for a relatively fixed number of third-party modules (if it is not fixed, memfs must not be able to carry infinite node_modules modules), and the access speed of memfs is much faster than network request access, so it is very Suitable for the realization of building systems. The second type is suitable for the number of third-party modules is not fixed, and there is no obvious real-time requirement for compilation speed. This type is more suitable for webide scenarios like codesandbox, and businesses can independently choose the npm modules they want.

Shims and Polyfills

Another problem encountered by web bundler is that most of the community modules are developed around node, which will rely heavily on the native API of node, but the browser does not support these APIs, so these modules are directly run on the browser. There will be problems. At this time, there are two situations...

Simulating Node Utility APIs

One is that these modules actually rely on some node utility APIs such as utils, path, etc. These modules do not actually depend on node runtime. At this time, we can actually simulate these APIs on the browser. Browserify is actually designed to solve this kind of scenario, providing a large number of node API polyfills on the browser, such as path-browserify, stream-browserify, etc. These polyfills allow developers to utilize Node-like functionality within the browser environment, bridging the gap between server-side and client-side code.

Separating Browser and Node Logic

The other situation is to process the logic of the browser and node separately. Although the code of node does not need to be executed on the browser, it is not expected that the implementation of node will increase the size of the browser bundle package and cause errors. At this time, we need node-related modules to be externally processed. This means that the code specific to the Node environment is isolated from the browser bundle, ensuring that the browser does not have to load unnecessary code that it cannot execute.

A Little Trick

A little trick to handle this situation, especially when configuring external may be troublesome or impossible to modify the bundler configuration, is to wrap require in eval, and most bundlers will skip the packaging of the require module. Such as eval(‘require’)(‘os’). This trick allows developers to bypass certain bundling constraints, providing more flexibility in handling platform-specific dependencies.

In conclusion, shims and polyfills play a crucial role in bridging the differences between the Node and browser environments. By simulating Node APIs or separating logic based on the platform, developers can create more portable and efficient code that runs smoothly across different environments. Whether it’s through the use of existing libraries like Browserify or clever coding tricks, these techniques are essential tools in the modern web development toolkit.

Web Assembly

Web Assembly (Wasm) is a binary instruction format that allows code written in languages like C++ to be executed in a web browser. This technology has opened up new possibilities for web development, enabling performance-critical applications to run at near-native speed. However, integrating Web Assembly into a web project can present challenges, particularly when it comes to managing file size.

C++ Modules and Web Assembly

In many businesses, including the one described here, C++ modules are essential. In a local environment, C++ can be compiled into a static library and called through Foreign Function Interface (FFI). However, in the browser, it needs to be compiled into Web Assembly to run. This compilation process can result in large file sizes. For example, the Web Assembly module of esbuild is about 8MB, and a custom-compiled static library may also be around 3MB. These large file sizes can have a significant impact on the overall package size, affecting load times and user experience.

Code Splitting Solution

A potential solution to this problem is to apply code splitting techniques to the Web Assembly modules. By dividing the Web Assembly code into “hot” and “cold” segments, developers can optimize the loading process:

— Hot Code: This segment includes the code that is most likely to be used during the initial access. By loading only this portion of the Web Assembly module at first, the initial load time can be reduced, enhancing the user experience.
— Cold Code: This segment includes the code that is less likely to be used or only needed in specific scenarios. By deferring the loading of this portion, the overall package size for the initial load can be minimized.

Applications of esbuild

esbuild is a versatile tool that offers three core functionalities, each of which can be used independently or in combination with the others:

Minifier: Reduces the file size of code by removing unnecessary characters and spaces.
Transformer: Converts code from one form to another, such as from TypeScript to JavaScript.
Bundler: Combines multiple files and dependencies into a single file for easier distribution.
Below are some specific applications where esbuild can be utilized:

Enhanced Registration and Minification Tools

By leveraging esbuild’s transformation function, developers can use esbuild-register to replace the registration of unit test frameworks like ts-node. This substitution significantly boosts the speed of the process. An example of this can be found at github.com/aelbore/esb. Additionally, since ts-node now supports custom registers, it's possible to directly replace the register with esbuild-register. When it comes to minification, esbuild's performance surpasses that of terser by more than 100 times, making it a highly efficient choice.

Node Bundler: A Case for Bundling in the Node Community

Unlike the front-end community, the node community rarely employs bundling solutions. This discrepancy arises partly because node services may utilize operations like file system (fs) and addons that are not bundle-friendly. Additionally, most bundling tools are designed with the front-end in mind, leading to the need for extra configuration when applied to the node domain.

However, bundling node applications or services offers significant advantages:

Reduction in Node Modules Volume: Bundling can decrease the size of node_modules, accelerating installation. By installing only the bundled code instead of numerous dependencies, the installation volume is greatly reduced, speeding up the process. Tools like pnpm and yarn exemplify this approach (source).
Enhanced Cold Start Speed: Bundling can improve the cold start speed of applications by reducing the JS code size through tree shaking. Since parsing overhead is a significant factor in the cold start speed of large applications, this reduction is especially beneficial for applications sensitive to cold start times. Additionally, avoiding file IO further enhances the speed, making bundling suitable for scenarios like serverless that are sensitive to cold start.
Avoidance of Upstream Semver Disruption: Semver (Semantic Versioning) is a community specification with strict code requirements. Bundling the code can prevent upstream dependencies from causing application bugs, a crucial consideration for high-security applications like compilers.

Given these benefits, the author strongly advocates for bundling node applications, and esbuild offers ready support for node bundles.

Challenges and Limitations of esbuild

While esbuild offers many advantages, it’s essential to recognize some of its challenges and limitations:

Debugging Difficulties:

Language Barrier: esbuild’s core code is written in Golang, and users interact with compiled binary code and JavaScript glue code.
Debugging Constraints: Breakpoint debugging the binary code is nearly impossible using tools like lldb or gdb.
High Debugging Requirements: Debugging esbuild’s code requires pulling down the code, recompiling, and debugging, a process that is both demanding and complex.

Limited Target Support:

ES6 Targeting: esbuild’s transformer currently only targets ES6.
ES5 Considerations: Many developers, especially in certain regions, still need to consider ES5 scenarios. As a result, esbuild cannot be used as the final product on its own and often requires collaboration with tools like Babel, TSC, or SWC to transition from ES6 to ES5.

Performance and Size Issues with Golang WebAssembly (Wasm):

Performance Degradation: The performance of Wasm compiled by Golang is suboptimal, with a 3–5 times degradation compared to native performance.
Package Size: The Wasm package compiled by Go is relatively large (8M+), making it unsuitable for scenarios sensitive to package size.

Smaller Plugin API:

Limited Hooks: Compared to the extensive plugin API support in Webpack and Rollup, esbuild only supports two plugin hooks: onLoad and onResolve.
Functionality Gaps: While these hooks enable a wide range of tasks, they are still relatively limited. For instance, post-processing of chunks after code splitting is not supported.

Rust Port of Webpack? Rspack, the New Kid on the Block

Zack Jackson — Fri, 25 Aug 2023 22:00:50 +0000

Created by the ByteDance Web Infra team, Rspack is a Rust-based bundler. It’s known for fast performance, interoperability with the Webpack ecosystem, strong customization abilities, and defaults — letting users hit the ground running without needing to configure much. It’s been made to solve tough challenges in business settings, improving the experience of many developers.

We’ve officially open-sourced Rspack to encourage innovation and teamwork. Developers, tech fans, and anyone interested in web development are welcome to join us. Whether you want to explore, create, or just be part of something big, Rspack is ready for you.

// Detect dark theme var iframe = document.getElementById('tweet-1655538017669648385-153'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1655538017669648385&theme=dark" }

This article was translated, written by @hardfist

Rspack: An In-Depth Look

Why Develop Rspack?

ByteDance works with lots of big front-end applications, about 6,500, that take a long time to build, sometimes up to half an hour. They tried many ways to make the process faster, but nothing from the existing community tools worked well enough. After looking deeper into the problem, they found that no tools were quite right for what they needed, so they decided to create Rspack:

// Detect dark theme var iframe = document.getElementById('tweet-1646081461622128641-832'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1646081461622128641&theme=dark" }

Good Dev Start Performance: Engineers often run the npm run dev command multiple times a day. With large-scale projects, each run might require a 10 minute wait, causing significant inconvenience. Therefore, optimizing the dev start time became a crucial necessity.
Good Build Performance: The npm run build command is frequently executed in the CI/CD environment, determining the efficiency of application production delivery. In some instances, build times could reach 20 to 30 minutes, emphasizing the need for a more time-efficient solution.
Enough Flexible Configuration: ByteDance’s varied user project configurations haven’t been fully unified, leading to issues when migrating the Webpack configuration to other build tools. The need for a solution with the flexibility of Webpack was apparent.
Production Environment Optimization Capability: Prior to Rspack, community solutions encountered negative impacts on the production environment optimization. Ensuring product optimization in the production environment was a non-negotiable feature.

After examining four main areas in need of improvement and looking into existing solutions, it became clear that nothing quite met the specific needs of large-scale front-end applications. The decision was made to create Rspack, though not without challenges.

Rspack isn’t just an answer to existing problems; it’s a custom-built tool, carefully designed to fit unique build requirements of large projects and modern needs. It represents a thoughtful effort to enhance performance, flexibility, and optimization, with the hope of making a meaningful difference in the web development landscape.

The Ambitious Path to Rspack:

A thorough investigation into existing community solutions showed that there were no tools that fulfilled all the specific needs identified. This led to the decision to develop Rspack in-house. By shaping the tool to meet these challenges, the team embarked on an innovative path, crafting a customized solution that holds the potential to become a force to be reckoned with.

// Detect dark theme var iframe = document.getElementById('tweet-1694617380452962615-609'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1694617380452962615&theme=dark" }

Community Collaboration and Inspirations

Rspack’s development is a result of collective inspiration, guidance, and support from various projects and individuals in the community:

Webpack Team and Community: For creating an excellent packaging tool and a rich ecosystem.
@sokra: For significant work on the webpack project.
@scriptedalchemy: For creating the module federation and helping connect Rspack with the community.
SWC project (created by @kdy1): For support in Rspack’s dependency analysis, code transpilation, and compression.
esbuild project (created by @evanw): Inspiring Rspack’s concurrency architecture.
NAPI-RS project (created by @brooooooklyn): For support in Rspack’s node-binding implementation.
Parcel project (created by @devongovett): An early explorer of Rust Bundler, inspiring Rspack’s incremental build architecture.
Vite project (created by @尤雨溪): Its compatibility design with the Rollup community inspired the compatibility design of Rspack and Webpack communities.
Rolldown project (created by the Rolldown team): Explores using Rust to build a high-performance Bundler + compatible Rollup API, inspired the design direction of Rspack.
html-webpack-plugin project (created by @jantimon): Rspack forks this to avoid using webpack API not yet supported in Rspack.
Turbopack project: Inspired the AST-based path rewriting logic in Rspack.

Rspack’s unique appeal extends to its interoperability with the existing Webpack ecosystem, including loaders, API, and config. While boasting a seamless integration, Rspack offers an added advantage: it comes with “wheels on.” This means that developers can get started without the verbosity or complexity typically associated with powerful tools. The design philosophy of Rspack is to provide power as and when you need it, making it accessible for beginners yet robust for experts.

What sets Rspack apart is its commitment to compatibility without compromising on functionality. The team behind Rspack is constantly expanding the API surface by adding more of Webpack’s plugin hooks, ensuring a broad alignment with the existing ecosystem. This thoughtful inclusion provides a dual benefit: it allows for easy transition for those familiar with Webpack and opens up avenues for exploiting more advanced features.

The development environment at ByteDance, characterized by a vast portfolio of software and a high-speed iterative process, demands an agile and powerful tool like Rspack. With the capability to compile large codebases rapidly, integration with Webpack’s ecosystem, and a design that enables both ease of entry and advanced utilization, Rspack proves itself as a valuable asset.

To try out Rspack, view the repository: GitHub — Rspack and check the official website: Rspack Official Website.

Continue reading on JavaScript in Plain English »

Next.js 11, Module Federation, and SSR — A whole new world

Zack Jackson — Sat, 04 Sep 2021 22:10:41 +0000

Server-side rendering with Next 11 and Module federation is ready for prime time! Bonus: we got "hot" (live) reloading working on federated applications!

Its been a long and painful road to module federation inside a next.js application — but we have finally been able to remove most of that pain.

This is the first time I can confidently say that we have been able to achieve full-scale Module Federation in Next.js — not just client-side but server-side as well!

Months ago, we demonstrated the concept of code-streaming, the idea was to make Node work like a browser and download remote chunks, executing them under its process. This was seamless and easy but posed some security concerns and in the case of next.js, where we are unable to "hot reload" production, those required chunks would get "stuck" and your host applications need to be restarted in order to re-fetch new remote chunks what were updated.

Say hello to multi-server rendering!

The Module Federation Group has conjured up a more acceptable solution to solve Federated SSR. Our solution doesn’t just work with Next.js applications — but this article is going to focus on utilizing our new system within the context one Next.js

Jacob outlines more details around the underlaying architecture
Webpack Federation SSR | ebey.me
*Webpack Module Federation has been a game changer in the micro-frontend space allowing multiple SPA's to operate as one…*www.ebey.me

Huge credit and shout out to Jacob Ebey. A critical part and mastermind behind this architecture

Multi-server rendering is exactly what it sounds like, the remotes accept props from the host application and perform the render at their origin, sending back the pre-rendered HTML. The whole process is blazing fast and if you put it behind a CDN, its even faster. Since rendering a single component only takes around 10ms–20ms, and our parser only adds 5–7ms of overhead on larger payloads.

Once we get the markup from the remote origin, our parser converts the HTML back into React, if you are passing host-originated children inside a remote component, those children are re-connected to the host render tree and render context. So they are still able to participate in any app-specific context that takes place during the render cycle.

What’s important to note is that we are able to asynchronously render any remote components at their origins simultaneously, so an RTT waterfall does not begin to develop, the response time is as fast as the slowest response — just like a Promise.all

import {
  getOrCreateFederatedComponentCtx,
  federatedComponentsContext,
  federatedComponent,
} from "nextjs-shared";

import remotes from "../remotes";

const Header = federatedComponent("home", "./header");

function MyApp({ Component, pageProps, federatedComponentsCtx, shellData }) {
  return (
    <federatedComponentsContext.Provider
      value={getOrCreateFederatedComponentCtx(
        { remotes },
        federatedComponentsCtx
      )}
    >
      <Header items={shellData.header.menu} />
      <Component {...pageProps} />
    </federatedComponentsContext.Provider>
  );
}

Hydration and avoiding flicker

User experience needs to be seamless, so we cannot have any flicker happen during hydration. In order to achieve this, we utilize a mechanism similar to react-lazy-hydration, where we only hydrate parts of the react tree from HTML into interactive React at startup. This preserves the existing markup and suppresses any hydration problems that may happen. Once Webpack kicks in and the federated code is executed, the SSR’d remote module is then hydrated into a federated react component.

I use react-lazy-hydration quite extensively to improve performance, offloading expensive components so they are only hydrated when TTI is reached or that are about to be scrolled into view with intersection observer. So applying a similar tactic to federated SSR is perfectly acceptable to me, and very effective.

Module Federation and Chunk Flushing are back!

One big request from the community has been that packages like react-loadable or loadable-components are unable to "flush" out and render federated Javascript tags and style sheets that were used. Causing additional RTT as the remote container kicks in, and has to go download these additional JS chunks right away.

Our new solution solves this problem, server-side rendered federated modules also flush out their JS and CSS chunks under our latest architecture design. Order to the world has been restored!

While other third parties do not support federated chunk flushing, when using our fetchFederatedComponent function, the flush will happen as expected and we handle flushing of federated chunks independently. If you use code splitting, keep using loadable-components for your internal chunks but you would be able to use our federated functions for getting those critical assets rendered to the DOM during SSR.

We place the CSS and js chunks into next.js context so next is aware of these additional scripts the whole time — ensuring there's no flicker during rehydration, no additional RTT to slow down your load times.

Making Module Federation and Next.js play nice

Next.js does not support Module Federation out of the box, you will need to depend on a plugin from the Module Federation Group which provides support. As far as I am aware, there are no near-future plans to see Next.js support Module Federation out of the box and when it does arrive — there are slim chances that SSR support will be available. At the time of writing, I believe that the MF Group is the only organization that possesses the technology to offer a "no limits" capability on Next's platform.

The nextjs-mf plugin enables Module Federation on the client-side, regardless of SSR you will need this in order for Federation to work at all.

The Case for Module Federation on Next.js applications

Next.js is not modular, it's very monolithic and mostly focuses on faster monolithic builds. But this pattern isn’t sustainable, Next Zones attempts to get closer to a more modular setup, but you are still locked in at page verticals and cannot escape a full page reload when switching zones.

Federation enables us to make Next.js highly modular. You can develop a MegaNav that can be deployed independently of the rest of your application, or split teams up in a more granular and autonomous manner. Teams can own components and are not chained to a page, and those components can be easily distributed across other pages without needing to re-deploy an entire Next.js instance or multiple instances. You don't have to depend on npm package bumps as a way to distribute shared code and you don’t have to depend on third-party vendors for patterns like ESI in order to get some modularity.

With server-side rendering solved, there are no drawbacks to leveraging module federation to tame and scale Next.js far more effectively.

No Page Reloads!!

Next Zones had the right idea but it's time to wave goodbye to page reloads when jumping between apps and instead welcome Federated Page Routing.

And the 97 lighthouse score speaks for itself

The core concept here is that you stay on the host application and instead federate the page into that application, not reload, and SSR another page from another application. SSR costs money, avoiding a page refresh and instead, leveraging client-side routing to simply pull the page from another application is faster, cheaper, and a better user experience.

To make this possible, we take advantage of the mechanics of Module Federation and next.js a CatchAll route.

We have a primitive example of omnidirectional, distributed routing available on Github.
module-federation-examples/nextjs at master · module-federation/module-federation-examples
*Module Federation in Next.js depends on @module-federation/nextjs-mf It will not work unless you have access to this…*github.com

Each application exposes a route map via module federation and the CatchAll page federates all the remote route-maps together, then uses some simple pattern recognition to see if the current path matches any existing mapped routed from a specific remote, if it does we call that remote and get the federated page — if we are unable to resolve the route, or if a JS error occurs for any reason, the CatchAll route simply performs a window.location.reload() which would bounce the user back through your application infrastructure and either land them on another SSR route that wasn’t mapped, an external URL, or a 404 page.

This mechanism and how we designed the federation plugin for Next.js ensures that even if federated pages have an error, the Next.js route will not, guaranteeing that navigating between pages will always work, and in the worst-case falling back to a page reload.

// [...slug].js
import { createFederatedCatchAll } from "nextjs-shared"; export default createFederatedCatchAll(["checkout", "home"]);

and the magic behind createFederatedCatchAll

export function createFederatedCatchAll(remotes) {

  const FederatedCatchAll = (initialProps) => {

    const [lazyProps, setProps] = React.useState({});

const { FederatedPage, render404, renderError, needsReload, ...props } = {
  ...lazyProps,
  ...initialProps,
};

React.useEffect(async () =&gt; {
  if (needsReload) {
    const federatedProps = await FederatedCatchAll.getInitialProps(props);
    setProps(federatedProps);
  }
}, []);

if (render404) {
  // *TODO: Render 404 page
  *return React.createElement("h1", {}, "404 Not Found");
}
if (renderError) {
  // *TODO: Render error page
  *return React.createElement("h1", {}, "Oops, something went wrong.");
}

if (FederatedPage) {
  return React.createElement(FederatedPage, props);
}

return null;



};

FederatedCatchAll.getInitialProps = async (ctx) => {

    const { err, req, res, AppTree, ...props } = ctx;

if (err) {
  // *TODO: Run getInitialProps for error page
  *return { renderError: true, ...props };
}

if (!***process***.browser) {
  return { needsReload: true, ...props };
}

try {
  const matchedPage = await matchFederatedPage(remotes, ctx.asPath);

  const remote = matchedPage?.value?.remote;
  const mod = matchedPage?.value?.module;

  if (!remote || !mod) {
    // *TODO: Run getInitialProps for 404 page
    *return { render404: true, ...props };
  }

  ***console***.log("loading exposed module", mod, "from remote", remote);
  try {
    if (!***window***[remote].__initialized) {
      ***window***[remote].__initialized = true;
      await ***window***[remote].init(__webpack_share_scopes__.default);
    }
  } catch (initErr) {
    ***console***.log("initErr", initErr);
  }

  const FederatedPage = await ***window***[remote]
    .get(mod)
    .then((factory) =&gt; factory().default);
  ***console***.log("FederatedPage", FederatedPage);
  if (!FederatedPage) {
    // *TODO: Run getInitialProps for 404 page
    *return { render404: true, ...props };
  }

  const modifiedContext = {
    ...ctx,
    query: matchedPage.params,
  };
  const federatedPageProps =
    (await FederatedPage.getInitialProps?.(modifiedContext)) || {};
  return { ...federatedPageProps, FederatedPage };
} catch (err) {
  ***console***.log("err", err);
  // *TODO: Run getInitialProps for error page
  *return { renderError: true, ...props };
}



};

return FederatedCatchAll;

}

Interested in Federated SSR? Contact us!

Our fetch implementation of SSR is not open source and took immense time and effort to develop, for any companies interested in leveraging our technology, we are happy to hold a workshop or consult, the Module Federation Group does accept clients. We are the creators of Module Federation

You can get in contact:

Zackary.l.jackson@gmail.com

or over Twitter

ScriptedAlchemy

ebey_jacob

Or book a workshop directly
Next.js Federated SSR Workshop - Zack Jackson
*Workshop plus private access to source code that contains a reference architecture for Federated SSR on Next.js - 8…*calendly.com

Micro Frontend Architecture: Replacing a monolith from the inside out

Zack Jackson — Tue, 12 Nov 2019 02:42:12 +0000

How to modernize a legacy application with micro-frontend technology

Zack Jackson
This article is part of a series on micro-frontend applications and techniques for managing them.

The Problem

Let us assume there’s a Monolithic codebase. The monolith uses one of the backend templating engines or systems, jQuery, and has no real considerations for frontend — or worse, comes from a time before SPAs existed. Maybe it has some asset pipeline like Ruby on Rails does. In that case, you might have backend variables inside javascript files — like .js.erb files, or AEM Fragments. A coupled, spaghetti codebase that feels next to impossible to modernize.

You want to stop writing frontend code inside this monolith and move to more JavaScript oriented ecosystem, but how?

Most companies cannot afford (will not accept) the engineering downtime of a “tools down” rewrite. Features need to progress under active development. Those features are undoubtedly getting harder to release at the same speed.

The monolith needs should be broken down into smaller pieces in a progressive, transitional way. It cannot interrupt business

However, decoupling a monolith can be tricky, primarily when new API’s to support a JavaScript application need to undergo planning or development to support the frontend migration.

Iterative frontend development, micro frontend (MFE) implementation, and team autonomy are blocked while waiting for the necessary APIs to undergo development or finish and go into a release cycle. FALSE, you can decouple the frontend in parallel to backend

Zack Jackson — ScriptedAlchemy
Here is one solution to decouple a frontend and port it to a standalone MFE complete with SSR. This method allows a team to do so without waiting for backend API’s to be abstracted and decoupled into microservices or even consumable API’s within the monolith. Replace the monolith from the inside out

The Blockers

Micro frontends typically have these two necessary dependencies.
1) Authentication
2) Data to feed the application, both in the browser and during server-side rendering (SSR)
In my experience, user authentication seems always to be the hardest part to separate from a monolithic backend. Regardless of if the legacy system is Rails, Java, .Net, etc.
There are other challenging aspects to micro frontend architecture, which will be elaborated on in a future series. So stay tuned!

Use the Monolith as a Layout Engine

There are a couple of different architectural specifications for MFE platform design. This article will focus on an adapted specification which is popular amongst backend microservices — LOSA (Lots Of Small Applications)architectureis a good option for “inside-out” migrations.

LOSA Request/Response flow via the monolith. Image credit to Robert Arkwright
LOSA applications (micro frontends in general) are standalone Node.js services capable of server-side rendering a part or fragment of a webpage that the service as mentioned earlier is responsible for servicing. A page can be made up of multiple LOSA services. These apps/or micro-frontends are built and deployed to a container which is independent. Operating in a standalone manner

The same web page, composed three different ways, demonstrating an incremental migration path. Starting as a monolith rendered page, transitioning to LOSA micro frontends and finally ending up as a micro frontend verticle, completely replacing the monolith. Image Credit Robert Arkwright
The monolith remains responsible for handling an HTTP request object, sending the final response to the client. Micro frontends can stay behind a firewall within the cluster — only available directly to the legacy system until such a time when an API gateway & user authentication can be decoupled (or at least turned into an API endpoint). You don’t need many changes to prepare these frontends for their post-monolith life.

The Render Flow

Below is modeled example of what a request/response could when up resembling.
First, a request is made:
GET/POST 'https://MFEwebsite.com/parts/header?format=json

Rendering a page can require a variety of data, any “missing” information that cannot yet be queried from a decoupled endpoint can be sent to_the_MFE (_micro frontend) as props_during the request. Heres what the MFE does when a request is made, the request is passed through a piece of middleware which is responsible for rendering the react application, a query is made to any necessary APIs that are decoupled and its response is sent back to it as props. These props will make up window.INITIAL_STATE

The code

If you are in need of some inspiration on how to implement some of these template functions or filters, then Hypernova is worth looking at. I haven’t used Hypernova, always opting to build my own. I have implemented similar mechanisms into Rails, Node, and PHP backends. Due to the proprietary nature of various backend platforms, I’ll be using Hypernova’s examples to convey a rudimentary concept.
Here is what an MFE rendering endpoint would look like in express:
The request from another system, in this case — the monolith
GET/POST 'https://MFEwebsite.com/parts/header?format=json

{
   html: '<div> ... </div>',
   css: '/static/header.3042u3298423.css',
   js: '/static/header.idhf93hf23iu.js',
   initial_state: {items:[...]}
}

The middleware that handles the response:

export function exampleRenderAPIware(req, res) {
  const renderedMarkup = renderHTMLpage(
    req,
    this.index,
    intial_state,
  );
  asyncRender.then(() => {
    const responseObject = {
      html: renderedMarkup,
      initial_state,
      js: jsResource,
      css: cssResource,
    };
    res.status(200).end(JSON.stringify(responseObject));
  });
}

Controllers making these initial POST requests should handle the responses, placing JS and CSS into the right locations. And finally rendering the react app into the appropriate spot in the legacy template. Here’s an example of what that legacy template looks like now. The assets, usually handled by some other controller in your monolith, will be responsible for injecting those scripts and styles into what’s left on the legacy header and bottom of the body tag. Remember, the monolith still serves as the layout engine. We are replacing parts, and adding new features in a React SSR way. Eventually, these LOSA apps could be stitched back together under one MFE or with Webpack black magic I’m developing. Known as webpack-external-import

What about migrating from template data to a new API?

When a new API is decoupled and brought online, what can be expected in migration?
When the monolith is providing the data to an MFE, express.js accesses this information off the HTTP request body. Now express would need to asynchronously fetch from the API. Data formats might have changed, but React still receives props. Underwhelmingly straightforward.

Performance

Compared to older monoliths, the new LOSA (lots of small applications) architecture wasn't performant enough, taking 400–600ms for a part of the page to render. We used Async Worker structures, meaning that instead of one SSR’d app, we could ask multiple services to SSR different parts of the application. This made it very hard to bring production offline because a “production failure” meant maybe losing a sidebar or footer for 10 mins till it was fixed. Separation of concerns at its finest.
Here’s what I mean by LOSA async workers. There were many node services, each responsible for rendering a component/components

Controllers (the grey gear) powering a legacy backend view can divert the view data to a post request instead of to a backend templating engine. Recycling data means there isn’t much effort required on the backend to support these mechanics. Avoiding major modifications will free up most of backend engineering to focus on decoupling data providers, while the frontend can progress independently. Since the view data was posted to an external react service, the response to that POST, which contains markup — is then passed to the backend templating engine, along with stylesheet, initial state, and CSS URLs. The templating engine now just renders the response from the POST request, thus decoupling your view or part of it from the legacy monolith.

React Render Time

React was slow!! SSR just isn’t fast — so our new react solution LOSA architecture wasn’t performant enough to be viable. Our solution, Fragment caching inside react

* Yellow: No React fragment caching — end-to-end(+-400ms)
* Dark purple: With React fragment caching — End-to-end (+-150ms)
* Orange: The fully optimized architecture (+-20ms)
* Green(at bottom of data points): native fragment cache from the backend
I will need to write another article to detail the whole process around creating a fully optimized react server (Sorry Anton Korzunov ). The Graphana data shows that we at least doubled our render performance, the round robin-times were still really slow. While internally, react was able to render very quickly — the end-to-end times were not as performant as we hoped. At least 150ms. As you can see, and as I’ll elaborate on in the next article — I can compete with fragment backend fragment caching.

Render time vs round-robin time

Render times are part of the challenge but even after implementing fragment caching inside React. I was disappointed to see that while our internal render times within Node.js were blazing fast (around 20ms). The whole end to end trip still took 140–200ms.

What are the bottlenecks

1   JSON size, specifically initial application state. Send the bare minimum state needed to render the page. Stop dumping so much stringified state into the initial render. Send enough state so React is able to re-hydrate and maybe some extra state for making above the fold components interactive immediately.

2   The number of DOM nodes to render — stop wrapping your code in useless divs, just to put a class on it. Take advantage of the semantic nature of HTML and the cascading effects of CSS. You end up writing way less markup, thus causing way less React.createComponent functions to be generated.

3   Garbage collection — more details will follow in a followup article series

4   Only as fast as the data providers. — Make use of Redis caches in the middle tier. If you throw the “cache invalidation is hard” argument at me then look at event sourcing. Even better, tackle the problem with CQRS and async workers on the writes and reads.

5   HTTP overhead between monolith and MFE — gRPC, CQRS, UDP, Protobuf. This communication between the monolith and your MFE should be happening internally over kubernetes networks. POST is slow, but works. When you hit the problem, handle it accordingly.

How I outperformed a backend rendering

Templatization, fragment caching, and gRPC/CQRS, removing bloat from the initial state JSON. React is slow(er) on the server. It's easy to forget, no abstraction is faster, only less slow.

What about scale?

Any good solution needs to be cost-effective at scale. Operating costs grow to astronomical amounts. Money talks, bad performance costs. I build cheap solutions at scale. Heres ways where perf can cost you:
1) paying for expensive third-party services to shoulder the load
2) paying for more / bigger containers
3) missed revenue due to bad performance
4) The monolith usually causes release cycles or deployment traffic jam’s as two branches cannot going into master at the same time.
5) Developers can move faster in lower-risk environments, business is able to deliver new ideas to market and roll back problematic areas — a team that can move fast and efficiently is a cost-effective enabler to business.

The result

Traffic: 10 million (renders) / day
Resource Allocations:
* Instances: 5
* RAM: 100mi (100 megs of ram)
* CPU: 100 (single-core)
* Max CPU usage threshold: 65%
* Response time: 20–25ms
* DOM Complexity: High
* 95% reduction in response time.

* Green: Backend render times
* Blue: React With Fragment Caching and state optimization.

My single-threaded javascript application was faster than a multi-threaded backend system with a fully-fledged fragment cache.

Follow me on twitter :)
DM me if you are in need more information or a consultation.
In the next series — I shall elaborate on the performance aspect that was briefly mentioned towards the end of this article.

Forem: Zack Jackson

The Future of Module Federation

The Future of Module Federation

Hooks

Framework APIs

TypeScript Support and Remote Types

Initialization Phases

Lifecycle

Middleware:

Startup

Examples and Applications

4-Way Handshake

Startup Hooks/Lifecycle

Explanation of Startup Hooks

Middleware & Startup as a whole

Middleware

Startup

Combined Effect

Runtime API / SDK

Plugin Hooks

Compile Time Hooks for Module Federation:

Initialization Hooks

“Filesystem” Hooks

Template Generation Hooks

API Manipulation Hooks

Using (Web|Rs)pack Runtime as a Library? A Possibility

Wrapping it up

Rspack 0.3 Release Announcement

Breaking Changes

Removal of @rspack/postcss-loader and builtins.postcss

Removal of Built-in CSS Autoprefixer Functionality

Access to Internal Modules Restricted

Major Feature Updates

Web Workers Support

builtin:swc-loader Support

Improved Profile Support

More Hook and Plugin Support

Alignment with Webpack Architecture

Rspack Ecosystem

Announcing Rspack 0.2

Main feature updates

Loader

Plugin Hooks

realContentHash

ESM/System format

New SplitChunksPlugin implementation

DataURI support

Breaking Changes

Webpack Compatibility Updates

fork-ts-checker-webpack-plugin

license-webpack-plugin

style-loader & css-loader

node-loader

Framework Ecosystem Updates

Modern.js Framework

Modern.js Doc

Vue

Svelte

Storybook

Angular

NestJS

Benchmark

Dev guide

Test infrastructures

Nightly Release

Acknowledgements

Bundler Design: A Comprehensive Exploration of Modern Bundling Technologies and Techniques

Rust Port of Webpack: Rspack | Medium

Zack Jackson ・ Aug 24, 2023 ・ scriptedalchemy.Medium

What is a Bundler?

How bundlers work

Comparison of LLVM and Bundler

Example: Rollup Process

Generating the Module Graph

Generating the Module Graph

Output

Generating the Content

Generated Content

Plugin System:

Core Hooks of Input Plug-in Systems

`builtin:swc-loader` Support

New `SplitChunksPlugin` implementation

Zack Jackson ・ Aug 24, 2023 ・
scriptedalchemy.Medium