Micro-frontend Architecture: Dynamic import chunks from another Webpack bundle a...

The challenges and solutions to importing chunks from other Webpack bundles at runtime, using them as if there were always there. Writing a Webpack plugin that bridges the gap.

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

Context

Building modern distributed JavaScript applications is complex, managing multiple repositories, builds, and code sharing is a complex and manual effort. I want to build standalone micro frontend applications that work together as one when in the browser.

H ere’s some additional context: https://github.com/webpack/webpack/issues/8524

The challenges of interleaving

Many webpack builds to act as one when in the browser, without context as build time

I’ve been using LOSA architecture, monolith strangulation, and custom micro-frontend setups — the problem that always plagues these platform designs is managing precious client-side runtime performance and bundle size. Scale and separation of concerns has some drawback in the browser

Interleaving Runtime

To put it bluntly, I want to merge two Webpack manifests at runtime and have them work together as if it was compiled as one SPA from the start. Kind of like DLLPlugin but without the requirement for passing context at build time — rather passing context at runtime

in·ter·leave

2) mix (two or more digital signals) by alternating between them.

Zack Jackson | ScriptedAlchemy

It would enable micro-frontends (or MFE’s which is what ill refer to them as) to work together seamlessly.

Smart code-splitting between builds. dynamic importing URLs, no page reloads

The goals

Interleaving needs to achieve the following

• No page refreshes when routing to another MFE, multiple apps should route as one SPA would
• Don’t redownload vendor code that is already provided by another Webpack build on the page. (Don’t bundle multiple copies of the same dependency)
• Each MFE should be completely standalone and have no centralized dependency. I don’t want to share code by managing Webpack externals, or commons vendor chunks
• Frontend resources should have the ability to be evergreen, not requiring a consumer to re-install.
• I should not need to redeploy the whole fleet because of a change to a shared component or something managed by another team (such as navigation, I don’t want to redeploy my all whenever they push a new update)
• Orchestration should be completely managed in user-land, allowing dynamic adaptations based on what JavaScript bundles are loaded on a page. There should be no remote logic or calls required beyond adding static JavaScript like the bundles themselves.