Micro‑Frontend Architecture with Vue: Concepts, Scenarios, and Implementation Guide

The commercial FE department of a large company maintains multiple back‑office applications built with a unified Vue stack; adopting a micro‑frontend architecture improves reuse and enables teams to work more efficiently on shared UI and logic.

Understanding – Micro‑frontend is a solution, not a technology, similar to micro‑services. It decomposes a large, complex front‑end into independent sandboxed applications that communicate through a set of shared rules.

Characteristics – Each sub‑application runs in its own sandbox with independent development, testing, and deployment pipelines; multiple apps can share dependencies such as modules, routes, or business components.

Typical Scenarios – Consider micro‑frontend when an app is large with many business logics, aligns with different organizational structures, has extensive logic reuse across apps, or undergoes continuous iteration.

Paradigm Diagram

The base‑style micro‑frontend consists of a base (host) project plus multiple child applications.

Runtime Collaboration

The base project acts as an organizer and should:

Load child app static resources on demand.

Dynamically register child apps and their key modules (router, store, etc.).

Deployment

During deployment, registration information must be synchronized to a registry module, which can be a simple JSON file or a dedicated service. For the current low volume of sub‑apps, a file‑based manual update is used.

The registry should provide:

Mapping of full sub‑app info (deployment time, version, assets, scope ID).

Dynamic updates as new deployments occur.

Readable output (object or self‑executing function).

Development

Two development modes are described:

Local service mode – Developers pull the base project locally and run it together with the child app, allowing direct import of the child’s build output for hot‑update handling.

Centralized service mode – The base runs on a shared development server, supporting coordinated multi‑team development but requiring network‑based resource loading and more complex setup.

For rapid rollout, the local service mode is chosen. The base project is named Voo .

Code Snippets (Local Service)

export default (Voo) => {
    Voo.Vue.prototype[appName] = vuePrototypeExtension;
    return { router, store, App };
}

Child app entry wrapper exposing router, store, and App modules.

export default [
  { 'path': '/', 'redirect': 'home' },
  { 'path': 'home', 'name': 'Home', 'component': Home }
];
export default { state, mutations, actions, modules };

Webpack configuration adjustments for UMD output and hot‑update handling:

webpackConfig.output.library = '[name]';
webpackConfig.output.libraryTarget = 'umd';
webpackConfig.output.jsonpFunction = appName;
webpackConfig.plugins.push(new webpack.BannerPlugin({
  'banner': '/* eslint-disable */',
  'raw': true
}));

Dev server hook to register child apps:

before(app, server) {
  app.post('/__dev_subApp_register', (req, res) => {
    const params = Object.assign(req.query, req.body);
    const info = `/* eslint-disable */
export default (registSubApp, opts) => {
  import('${params.resourcePath}').then(res => {
    const subApp = res.default(opts);
    registSubApp({ id: '${params.id}', subApp });
  });
}`;
    fs.writeFileSync(`${__dirname}/__dev__subApp_register_info.js`, info);
    res.json({ code: 0, message: '开发时注册成功' });
  });
}

Centralized Service – Uses Nginx reverse proxy to the base service and registers child apps via a devServer endpoint. Sub‑apps are stored under /subApps with a simple directory layout.

const requireSubApps = require.context('./', true, /\.js|\.css$/);
export default requireSubApps.keys().map(fileName => requireSubApps(fileName).default);

Hot‑update logic triggers registration when a child app changes:

before(app, server) {
  registe();
  app.post('/__dev_update', (req, res) => registe());
}
if (module.hot) {
  module.hot.accept('./main.js', () => {
    fetch('/__dev_update');
  });
}

Reuse Layer – Classified into class‑type (instantiated per use) and function‑type (shared code). Management strategies include npm scopes for version‑locked libraries and global registration for shared UI components.

Typical reusable assets:

UI component libraries (class‑type).

Ajax utilities and unified API handlers (function‑type).

Business components (both).

Specialized child‑app components such as charts or workflows (class‑type, hosted on npm).

Sub‑App Granularity – Overly coarse or fine granularity harms maintenance; the recommended split aligns with back‑end services and team boundaries.

Q&A

Q: Why does the local service mode import the child app’s bundle instead of its entry file? A: Importing the bundle keeps the child app decoupled from the base, avoiding build differences between development and production and preventing the child from inheriting base‑specific dependencies.

Summary and Outlook

The proposed architecture solves business fragmentation, enables multi‑team autonomous development, supports agile iteration, reduces the learning curve for sub‑app developers, and makes sub‑apps feel like standalone SPAs.

Future work includes supporting cross‑technology‑stack sub‑apps, centralizing the base as a service (potentially SSR), and turning the registry into a managed service.