Micro‑Frontend Architecture for a Supply‑Chain System Using Single‑SPA

Background

Traditional front‑end projects in the supply‑chain domain grew into a single large monolith covering many business lines, leading to massive bundle sizes, slow compilation, long build times, and frequent merge conflicts that reduced development efficiency.

Problems

The monolithic system suffered from numerous issues such as an ever‑increasing number of files, slow compilation (project start takes minutes), lengthy Jenkins builds, queueing for releases, full‑bundle rebuilds for tiny changes, and long bug‑locating cycles.

Requirements & Expectations

The team aimed to split the monolith into a main project plus multiple child projects forming a front‑end micro‑service system, with goals of decoupling by business domain, accelerating development and release cycles, minimizing intrusion to existing code, keeping learning cost low, and enabling zero‑cost rapid onboarding of new modules.

Technical Selection

After evaluating qiankun and Single‑SPA, the team chose Single‑SPA for its lower integration constraints and flexibility, using it as the core framework for the micro‑frontend solution.

System Architecture

The architecture consists of three parts: a Node service for service discovery, the main (host) project, and multiple child projects. The Node service watches child project directories and generates project_config.json describing routes, messages, and entry files.

Service Discovery

A Node script monitors file changes in child project folders, aggregates their micro-project.json and micro-manifest.json files, and produces a unified configuration that the host project loads at startup to register child applications.

Module Loading

Child projects are loaded lazily via SystemJS using AMD‑style bundles; the host inserts an import‑map into the page head that maps project names to entry files, and SystemJS loads the appropriate bundle when a matching route is activated.

Message Bus & Data Sharing

A global event distributor (GlobalEventDistributor) is created in the host to register each child’s Redux store, dispatch actions, and retrieve state. Public data (global, otms, tabs) is stored centrally in the host’s Redux store; children receive updates through the bus, and all modifications to public data are funneled through a saga middleware that tags actions with MICRO_SAGA_TAG_ and forwards them to the host for execution.

Build & Deployment

Each child project produces micro-project.json (development config) and micro-manifest.json (webpack‑generated manifest). After merging, the host and children are placed together in a single directory structure, and Jenkins builds the whole set without special post‑processing; a post‑deployment command triggers the Node service to refresh service‑discovery data.

Results

The monolith was split into two child projects plus a host, reducing build time from 9.54 s to 7.9 s, eliminating release queueing, and providing a scalable foundation for future business lines while improving developer experience.