How We Scaled a Vue-Based Supply Chain Platform with Micro‑Frontends and Single‑Spa

Introduction

Micro frontends extend the micro‑service idea to the browser. The term appeared in the 2016 ThoughtWorks technology radar and addresses the maintenance problems of large single‑page applications built with many backend services.

Requirements and Outcomes

The supply‑chain frontend team uses Vue for dozens of B2B applications, each with its own HTML entry. Switching between them caused full page reloads and high maintenance cost. A new demand required extracting selected features from many projects into a single application without reloads.

We adopted Single‑Spa (instead of iframe) and achieved:

One main project with a single HTML entry; sub‑projects are loaded on demand, eliminating page refreshes.

Shared UI (menu, login, logout, monitoring) lives in the main project, so only it needs to be updated.

Common libraries (Vue, Vuex, Vue‑Router, iView, private npm packages) are loaded by the main project via webpack externals, reducing each sub‑project bundle by about 80 %.

A tab system based on keep‑alive gives a near‑native browser‑tab experience.

Development cost for the new requirement dropped dramatically, and the architecture can accommodate future sub‑projects.

Demonstration and Technical Points

Before the migration the blue area of the UI was shared by all sub‑projects, causing full reloads. After migration only the orange area changes and the page no longer refreshes.

Each tab originates from an independent Vue repository, and the hash‑level route determines which sub‑project to load.

Architecture Components

Loader : the core JavaScript that registers and loads projects.

Wrapper : adapts existing Vue projects so the loader can handle them.

Main project : the base application that hosts shared resources.

Sub‑project : the individual feature applications.

The loading flow is: the browser loads index.html, the loader reads apps.config.js, registers all projects, loads the main project, then dynamically loads the appropriate sub‑project based on the route.

Some Technical Details

SystemJS

SystemJS (v0.21) is used for remote loading of sub‑projects. Each sub‑project must be built as a UMD bundle so SystemJS can import it.

// Example of a sub‑project’s webpack.config.js output section
output: {
  path: xxx,
  publicPath: xxx,
  filename: '[name].[chunkhash:8].js',
  chunkFilename: 'js/[name].[chunkhash:8].chunk.js',
  libraryTarget: 'umd', // must be UMD
  library: xxx
},

Webpack Externals

Common libraries are externalized to avoid duplication. The externals are mapped to CDN URLs in the SystemJS configuration.

// Sub‑project webpack externals configuration
externals: {
  'axios': 'axios',
  'vue': 'Vue',
  'vue-router': 'VueRouter',
  'vuex': 'Vuex',
  'iview': 'iview',
  'moment': 'moment',
  'echarts': 'echarts',
  '@mfb/pc-utils-micro': '@mfb/pc-utils-micro',
  '@mfb/pc-components-micro': '@mfb/pc-components-micro'
}

// index.html – single entry point
<script src="system.js"></script>
<script>
  SystemJS.config({
    map: {
      "Vue": "//cdn.example.com/vue/2.5.17/vue.min.js",
      "VueRouter": "//cdn.example.com/vue-router/3.0.1/vue-router.min.js",
      // other CDN mappings …
    }
  })
</script>

SystemJS registers these CDN URLs but only loads a library when a sub‑project actually requires it, preventing unnecessary network traffic.

Conclusion

The micro‑frontend architecture reduces bundle size, improves user experience, and enables flexible composition of many independent Git repositories into new applications. It also introduces challenges such as global‑variable pollution, style conflicts, and extra effort to manage keep‑alive caches. The approach is best suited for large, modular front‑end ecosystems rather than small projects.