Complete Micro Frontend Architecture Guide

Introduction to Frontend Architecture Evolution

Frontend development has undergone a dramatic transformation. What started as simple HTML pages has evolved into complex, feature-rich applications that rival desktop software in functionality and user experience.

The Evolution Journey

Current State of Frontend Development (2025)

• Massive Applications: Modern web apps like Netflix, Spotify, and Figma rival desktop applications in complexity
• Large Teams: Companies have hundreds of frontend developers working on the same product
• Rapid Deployment: Daily or hourly deployments are the norm, not the exception
• Technology Diversity: Teams want to use the best tools for specific problems
• Performance Demands: Users expect instant loading and smooth interactions

Explore Our Micro Frontend Components

Discover the power of modular architecture with our three core components, each demonstrating different aspects of micro frontend implementation.

What Are Micro Frontends?

Micro Frontends are an architectural pattern that extends the microservices concept to frontend development. Instead of building a monolithic frontend application, you break it down into smaller, independently deployable applications that work together to create a cohesive user experience.

Core Principles of Micro Frontends

• Technology Independence: DEach team can choose their own tech stack – React, Vue, Angular, or even vanilla JS
• Independent Deployment: Teams own their entire stack from UI to backend services
• Team Autonomy: Teams own their entire stack from UI to backend services
• Fault Isolation: If one micro frontend fails, others continue to work normally

Real-World Examples

• Netflix: Different teams handle search, recommendations, player, and user profiles
• Spotify: Separate teams for music player, playlists, social features, and podcasts
• IKEA: Product catalog, shopping cart, checkout, and account management as separate apps
• Upwork: Job search, messaging, payments, and profiles as independent micro frontends

Why Your Application Needs Micro Frontends

The Problems with Monolithic Frontends

How Micro Frontends Solve These Problems

Success Metrics: Real-World Impact

Implementation Approaches: Choosing the Right Strategy

There are several ways to implement micro frontends, each with different trade-offs. Let’s explore the most popular approaches and understand when to use each one.

Why Module Federation is Leading the Way

Real-World Example: AlterSquare Canvas Demo Analysis

AlterSquare has created an excellent demonstration that showcases the true power of micro frontend architecture. Let’s analyze how their canvas application perfectly demonstrates the key benefits of this approach.

Architecture Overview

Why This Demo Perfectly Demonstrates Micro Frontend Benefits

Business Impact Demonstration

• 👥 Team Specialization: Autonomous drawing, shapes, and text teams own their domains end-to-end.
• ⚡ Rapid Feature Delivery: Ship new tools without modifying unrelated modules or waiting on global releases.
• 🧪 Targeted Experiments: Run A/B tests per module to de-risk changes and validate value quickly.
• 🔁 Technology Evolution: Upgrade canvas libraries or internals within a single demo in isolation.
• 📦 Lean Downloads: Users load only the features they need, improving performance.
• 🛡️ Fault Isolation: Failures are contained; shapes and text continue if drawing fails.

Real-World Example: AlterSquare Counter Demo Analysis

Architecture Overview

Why This Demo Is Powerful

Business Impact Demonstration

• 🎯 Consistent UX: One counter value across apps ensures predictable behavior for users.
• 🔗 Lower Coupling: Interfaces decouple UI from state mechanics, simplifying changes.
• ⚡ Faster Delivery: Teams evolve features independently without cross-repo coordination.
• 📈 Observability: Centralized logging of state mutations aids debugging and analytics.
• 🛡️ Fault Isolation: Consumer apps continue to work even if interface import fails.
• 🔁 Incremental Adoption: Migrate features gradually by exposing additional interfaces over time.

Best Practices for Implementing Module Federation with Vite

Module Federation allows multiple frontend applications to share code and features at runtime without bundling everything into one huge app. Instead of copying/pasting code or publishing shared libraries to NPM, apps can load each other’s components, stores, or utilities directly over the network. Think of it as microservices, but for the frontend.

In our setup, we have a Shell App (the container) and several Remote Apps (like a counter demo, canvas demo, etc.). The shell app decides which remotes to load, while each remote can expose parts of its code for others to use.

1. Configuring vite.config.js

Every app (shell or remote) must define a vite.config.js with the @module-federation/vite plugin. The key settings are:

• name: Unique name for this app in the federation.
• filename: The file generated that other apps will load (remoteEntry.js).
• exposes: Which local files/modules you want to share.
• remotes: References to other applications you want to consume.
• shared: Dependencies that must only exist once (singletons) across all apps (e.g., Vue, Pinia).

// vite.config.js (example from Shell App)
import { federation } from '@module-federation/vite'
import vue from '@vitejs/plugin-vue'
import { defineConfig } from 'vite'

export default defineConfig({
  plugins: [
    vue(),
    federation({
      name: 'shellApp',                  // this app's name
      filename: 'remoteEntry.js',        // output file others will load
      exposes: {                         // local modules we share
        './counterInterface': './src/interfaces/counter.js',
      },
      remotes: {                         // apps we depend on
        demoCounterApp: {
          type: 'module',
          entry: process.env.VITE_DEMO_COUNTER_REMOTE_ENTRY,
        }
      },
      shared: {                          // singletons across apps
        vue: { singleton: true, requiredVersion: '^3.5.18' },
        'vue-router': { singleton: true, requiredVersion: '^4.2.4' },
        pinia: { singleton: true, requiredVersion: '^2.1.7' },
        fabric: { singleton: true, requiredVersion: '^5.3.0' }
      }
    })
  ],
  optimizeDeps: {
    include: ['vue', 'vue-router', 'pinia', 'fabric'],
  }
})

In this example, the shell app can now consume modules from demoCounterApp (a remote), and at the same time it exposes its own counterInterface for others to use.

2. Sharing a Store Across Apps

State management is tricky across multiple apps. With federation, we can expose a Pinia store from one app and consume it in others. Because pinia is marked as a singleton in shared, all apps will reference the same store instance.

// Importing a counter store exposed by demoCounterApp
import { useCounterStore } from 'demoCounterApp/counterInterface'

export default {
  setup() {
    const counter = useCounterStore()
    return { counter, increment: counter.increment }
  }
}

3. Exposing a Vue Component (Fabric.js Example)

Besides stores, you can expose entire Vue components (for example, a canvas drawing tool built with Fabric.js). Any app can then import and render this component without duplicating the logic.

// DynamicCanvas.vue
<template>
  <div ref="canvasContainer" class="canvas-wrapper"></div>
</template>

<script setup>
import { onMounted, ref } from 'vue'
import { fabric } from 'fabric'

const canvasContainer = ref(null)

onMounted(() => {
  const canvas = new fabric.Canvas(canvasContainer.value, {
    backgroundColor: '#fff',
    selection: true
  })

  canvas.add(new fabric.Rect({
    left: 100, top: 100,
    fill: 'red', width: 60, height: 70
  }))
})
</script>

To expose this component in vite.config.js:

exposes: {
  './DynamicCanvas': './src/components/DynamicCanvas.vue'
}

Now another app can use it directly:

// Importing exposed component
import DynamicCanvas from 'demoOneApp/DynamicCanvas'

4. General Guidelines for Teams

To avoid headaches when scaling across multiple teams:

• Always use remoteEntry.js as the federation filename.
• Mark vue, pinia, vue-router as singletons.
• Add optimizeDeps.include for all shared deps to avoid duplication during dev.
• Namespace your exposed modules clearly (e.g., ‘./counterInterface’ vs ‘./interfaces’).
• Use .env variables for remote URLs — never hardcode them.
• Document which modules are safe for other teams to consume (stable APIs vs experimental).
• Share heavy libraries (like Fabric.js) to reduce bundle size.

5. Gotchas & Tips

Challenges & Solutions

Technical Challenges

Styling in Module Federation

Problem: Styles from remotes can fail to apply inside the host in dev (due to SFC scoped styles and injection order), and after build we don’t have precise control to “share” styles via JS.

Our solution:

• Dev: Exposed components use unscoped/global styles (avoid scoped on SFCs you expose) so the host can consume them as-is.
• Build: Extract all CSS into a single file per remote and have the shell load these stylesheets before mounting modules. This avoids relying on JS-injected styles post-build.
• Order & isolation: Load remote CSS deterministically; when needed, isolate using CSS Modules (hashed) or Shadow DOM for leaf widgets.
• Collision prevention: Namespace classes/IDs (prefix per app or BEM) to avoid overrides across apps.

Build output: single CSS file per remote (Vite/Rollup)

We configure each remote to emit one CSS file so the host can load it via a simple <link rel="stylesheet">. With Vite (Rollup under the hood), disable CSS code splitting and optionally choose a stable filename:

// vite.config.ts (in each remote app)
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

export default defineConfig({
  plugins: [vue()],
  build: {
    // Emit a single combined CSS file for this remote
    cssCodeSplit: false,
    rollupOptions: {
      output: {
        // Give CSS a predictable name so the shell can reference it
        assetFileNames: (assetInfo) => {
          if (assetInfo.name && assetInfo.name.endsWith('.css')) {
            return 'assets/remote.css' // or `${name}.css` per app
          }
          return 'assets/[name]-[hash][extname]'
        },
      },
    },
  },
})

Result: each remote publishes a stable CSS URL (e.g., /assets/remote.css) that the host can preload or load before mounting modules, ensuring correct cascade and fewer flashes of unstyled content.

Host: load remote CSS before mounting

The shell loads each remote’s CSS deterministically before creating the Vue app. This mirrors our build-time behavior and avoids relying on JS-injected styles after code-split chunks load.

// shell-app/src/main.js (build behavior)
const remotes = [
  { name: 'demo-one',   href: import.meta.env.VITE_DEMO_ONE_CSS_URL },
  { name: 'demo-two',   href: import.meta.env.VITE_DEMO_TWO_CSS_URL },
  { name: 'demo-three', href: import.meta.env.VITE_DEMO_THREE_CSS_URL },
  { name: 'demo-counter', href: import.meta.env.VITE_DEMO_COUNTER_CSS_URL },
]

for (const r of remotes) {
  const link = document.createElement('link')
  link.rel = 'stylesheet'
  link.href = r.href
  link.onload = () => console.log(`✅ ${r.name} CSS loaded`)
  link.onerror = () => console.error(`❌ Failed loading ${r.name} CSS`)
  document.head.appendChild(link)
}

// Then mount the shell app

Note: This isn’t heavy—these stylesheets are already built and hosted by each remote (or its CDN). The shell simply references them, so the cost is just a few cacheable GETs (often HTTP/2 multiplexed). You can also <link rel="preload" as="style"> to optimize first paint.

Turbo: Versioning & Selective Builds/Deploys

Problem: Keeping versions consistent across apps and rebuilding/deploying everything on each push.

Our solution with Turborepo:

• Consistent versions: Single workspace/lockfile keeps dependency versions aligned across all apps.
• Affected-only builds: Turbo uses git-aware change detection and task hashing to rebuild only impacted packages (with remote cache speeding CI).
• Targeted deploys: CI deploys only changed apps based on the affected graph, instead of redeploying the entire fleet.
• Example: turbo run build --since=origin/main and deploy only the apps whose build outputs changed.

What is Turborepo? A build system for JavaScript/TypeScript monorepos. It understands your package graph, runs tasks in the right order, and caches outputs locally or remotely so unchanged work is instantly reused.

How we use it (repo‑agnostic): Place each app/package in a workspace (e.g., apps/*, packages/*). Define tasks like build/test in each package.json. Turborepo executes those tasks respecting dependencies and uses content hashing (source, lockfile, env) to skip work when nothing relevant changed. To build only affected projects since a Git ref: turbo run build --since=origin/main.

Change detection workflow (example)

This CI-friendly script builds only affected projects and deploys just the apps that changed since a base ref. It’s intentionally simple and repo-agnostic.

#!/usr/bin/env bash
set -euo pipefail

BASE_REF="${BASE_REF:-origin/main}"
APPS_ROOT="${APPS_ROOT:-apps}"

echo "▶️ Building only affected projects since ${BASE_REF}"
npx turbo run build --since="${BASE_REF}" --output-logs=errors-only

echo "🔎 Detecting which apps changed since ${BASE_REF}"
changed_apps=()
for app in "${APPS_ROOT}"/*; do
  [ -d "${app}" ] || continue
  [ -f "${app}/package.json" ] || continue
  if ! git diff --quiet "${BASE_REF}"..HEAD -- "${app}"; then
    changed_apps+=("$(basename \"${app}\")")
  fi
done

if [ ${#changed_apps[@]} -eq 0 ]; then
  echo "✅ No app changes detected; skipping deploy."
  exit 0
fi

echo "🚀 Deploying changed apps: ${changed_apps[*]}"
for app in "${changed_apps[@]}"; do
  echo "--- Deploying $app ---"
  # Example: pnpm --filter "$app" run deploy
  # Or:      npm run -w "${APPS_ROOT}/$app" deploy
  :
done

Notes:

• This example detects direct changes inside each app. If you also have shared packages (e.g., packages/*), you can deploy dependents when those change by adding a small dependency map or by using Turborepo filters like --filter to include dependents.
• For even faster CI, enable Turborepo’s remote caching so identical tasks are restored instantly across machines.

Organizational Solutions

Decision Framework: When to Use Micro Frontends

Perfect Candidates for Micro Frontends

When NOT to Use Micro Frontends

Decision Matrix

Final Recommendations

Conclusion

Micro Frontend Architecture represents a significant evolution in how we build large-scale web applications. Like the microservices revolution in backend development, it addresses the fundamental challenges of scale, team coordination, and technology evolution.

AlterSquare’s canvas demo perfectly illustrates how micro frontends can solve real-world problems while maintaining excellent user experience. Whether you’re building the next Netflix, Spotify, or innovative canvas application, micro frontends provide the architectural foundation for sustainable growth.