Design Considerations and Challenges in Micro‑Frontend Architecture

The article outlines a micro‑frontend design framework aimed at avoiding the "giant stone" trap by partitioning a large monolithic application into smaller, independently deployable sub‑applications.

It explains that JavaScript sandboxing typically relies on Proxy wrapping of global objects such as window and globalThis , but this approach cannot guarantee 100% isolation, especially for asynchronous code, and is ineffective for ESM‑based sub‑applications.

CSS sandboxing is described as comparatively simpler, yet it requires complex parsing and cannot handle keyframe animations.

Preloading is introduced as a way to reduce latency by fetching a sub‑application’s resource mapping table and static assets ahead of activation, allowing immediate bootstrap and mount when the sub‑application is needed.

Release (unloading) is distinguished from simple sub‑application removal; it involves cleaning up the entire micro‑frontend environment, handling state‑machine transitions, and ensuring that asynchronous operations are aborted, with special attention to the BOOTSTRAPPING, MOUNTING, and LOADING_SOURCE_CODE states of single‑spa.

Nested micro‑frontends are discussed, noting that only one single‑spa instance can exist per page, which forces all nested main applications to share the same API and creates coupling challenges.

Cross‑application navigation is addressed by using an activeWhen function such as foo.activeWhen = (location) => location.pathname.startsWith('/foo/'); and a fallback router rule like { path: '/(.*)', beforeEnter: (to) => { history.pushState({}, '', to.path); } } to bubble navigation requests to the top‑level single‑spa.

The <keep-alive> component is presented as a caching mechanism for sub‑applications, allowing them to be hidden without full unmount, while still requiring CSS removal to avoid style conflicts.

Shared dependencies (e.g., Vue.js) are managed centrally by the host application, with a four‑state lifecycle (not loaded, loading, loaded, failed) to prevent duplicate global objects and version clashes.

Conflict detection is implemented via an ESLint plugin that warns on risky global variable accesses such as window.foo , globalThis['foo'] , or Vue.prototype.foo , with configurable patterns.

Joint development challenges are mitigated by extracting a common "foundation" library used by both host and sub‑applications during development, and later moving to a runtime dynamic dependency model that proxies the host’s HTML and resource mapping to local sub‑applications.

Resource mapping tables, which list all static JS and CSS assets, are generated by custom webpack and Vite plugins that write the tables to an in‑memory file for real‑time consumption during development.

An Asset Management System (AMS) centralizes these mapping tables on a CDN, reducing IDC resource consumption and enabling rapid rollbacks by switching the mapping configuration instead of redeploying services.

Finally, a progressive evolution strategy is proposed: start with a single‑page application that mimics micro‑frontend boundaries, then gradually extract sub‑application directories for independent deployment, ensuring a smooth transition to a full micro‑frontend architecture while maintaining development efficiency and future scalability.