Decentralized Micro‑Frontend Architecture with Vite Module Federation in Vue 3

In modern large‑scale front‑end projects, multiple teams often face code isolation and integration challenges; a decentralized micro‑frontend approach allows each module to be developed and deployed independently while still functioning as part of a unified system.

The solution presented relies on the Vite plugin @originjs/vite-plugin-federation , which enables cross‑application component and route sharing with dynamic loading. The article walks through the architecture design, comparing traditional “base‑app” micro‑frontend patterns with the proposed decentralized model that has no central base, equal collaboration, shared routing, and a shared runtime.

Key configuration snippets include the basic federation setup:

federation({
  name: "pageAModule",
  filename: "pageAEntry.js",
  exposes: { "./routes": "./src/routes/index.ts" },
  remote: { menuModule: ModuleUrl },
  shared: ["vue", "vue-router", "pinia"]
})

The menuModule provides a unified layout, menu management, permission control, navigation state, and system‑level utilities, and is imported by all other modules.

To overcome the limitation of static remote imports, a dynamic loader getRemoteEntries is implemented using the plugin’s get API. It fetches a registry.json file, filters modules, builds URLs at runtime, and loads the requested module and its exported route:

export const getRemoteEntries = async (name?, moduleName?) => {
  const response = await axios.get(`${baseUrl}/federation/registry.json`);
  const filtered = response.data.filter(/* filter logic */);
  const loaded = [];
  for (const info of filtered) {
    const moduleUrl = `${baseUrl}/${info.path}/${info.name.replace('Module','Entry')}.js`;
    const remote = await import(/* @vite-ignore */ moduleUrl);
    const factory = await remote.get('./' + moduleName);
    loaded.push(await factory());
  }
  return loaded;
}

Routing integration is handled by mergeLayoutChildren , which identifies the layout route, extracts “out‑layout” pages, and merges all child routes into the layout’s children array, preserving top‑level routes such as login and 404 pages.

State sharing across micro‑frontends is achieved with a Pinia cache store defined in src/stores/modules/cache.ts . The store offers namespaced keys, optional expiration, local‑storage persistence, and methods for setting, getting, and removing cached data, enabling direct state sharing, temporary shared data, and cross‑application global state.

The project structure is outlined, showing separate module directories (menu, user, other pages), each with its own vite.config.ts , routes, views, stores, and utility files. A sample vite.config.ts demonstrates how to expose routes, declare the remote menuModule , and share common dependencies.

Deployment relies on a central registry.json hosted on a CDN, which lists available modules (e.g., pageModule , menuModule ). At build time each module is packaged as an entry script (e.g., pageEntry.js ) that can be loaded dynamically by other modules.

In conclusion, the @originjs/vite-plugin-federation plugin provides a solid foundation for building a truly decentralized, flexible, and scalable micro‑frontend system, allowing independent development, testing, and deployment while maintaining overall consistency and usability.