DEV Community: Hemant Singh

From Monorepo to Polyrepo: Scaling Micro-Frontends Across Teams

Hemant Singh — Fri, 24 Oct 2025 05:17:22 +0000

From Monorepo to Polyrepo: Scaling Micro-Frontends Across Teams

Introduction

In my previous article, I explored building scalable applications with micro-frontends using a monorepo approach powered by Nx. While that approach works incredibly well for small-to-medium teams with shared ownership, I've since explored a polyrepo architecture that better addresses enterprise-scale challenges.

In this article, I'll share why I made the switch, the trade-offs involved, and real-world implementation details from a production deployment.

🎯 The Journey: From Monorepo to Polyrepo

Previous Approach: Monorepo

In the monorepo setup:

✅ Everything lives in one repository
✅ Nx manages dependencies and builds
✅ Shared libraries are TypeScript path aliases
✅ Easy local development
✅ Atomic commits across multiple MFEs

Example Structure:

mfeworld/                          # Single repository
├── apps/
│   ├── dashboard/                 # Host application
│   ├── products/                  # Remote MFE
│   ├── cart/                      # Remote MFE
│   ├── orders/                    # Remote MFE
│   └── profile/                   # Remote MFE
├── libs/
│   └── shared/
│       ├── layout/               # Shared components
│       ├── services/             # Shared services
│       └── utils/                # Shared utilities
└── nx.json

This worked great for:

Small teams (< 20 developers)
Shared ownership model
Rapid prototyping
Consistent tooling and dependencies

New Approach: Polyrepo

Now, each micro-frontend and the shared UI Kit live in separate repositories:

📦 Host Repository
├── https://github.com/hemantajax/mfe-host

📦 Shared UI Kit Repository
├── https://github.com/hemantajax/mfe-uikit
└── Published as: @hemantajax/mfe-uikit

📦 Remote MFE Repositories (8 separate repos)
├── products/      → https://hemantajax.github.io/mfedemos/products/
├── cart/          → https://hemantajax.github.io/mfedemos/cart/
├── profile/       → https://hemantajax.github.io/mfedemos/profile/
├── orders/        → https://hemantajax.github.io/mfedemos/orders/
├── analytics/     → https://hemantajax.github.io/mfedemos/analytics/
├── notifications/ → https://hemantajax.github.io/mfedemos/notifications/
├── messages/      → https://hemantajax.github.io/mfedemos/messages/
└── admin/         → https://hemantajax.github.io/mfedemos/admin/

🔗 Live Demo - See it in action!

🤔 Why Polyrepo? The Business Case

1. Team Autonomy & Ownership 🎯

Problem in Monorepo:

All teams share the same repository
PR bottlenecks when multiple teams work simultaneously
Difficult to enforce team boundaries
Shared CI/CD pipeline can block deployments

Polyrepo Solution:

# Products team owns their repo completely
products/
  ├── .github/workflows/       # Their own CI/CD
  ├── src/                     # Their code
  └── package.json             # Their dependencies

# Cart team owns their repo
cart/
  ├── .github/workflows/       # Independent CI/CD
  ├── src/                     # Their code
  └── package.json             # Their dependencies

Each team can:

✅ Set their own release schedule
✅ Choose their own tooling (within agreed standards)
✅ Deploy independently
✅ Control their own PR process

2. Independent Deployment Pipeline 🚀

Monorepo Challenge:

# Single pipeline for all apps
build-all:
  - Build: dashboard, products, cart, orders... (15+ minutes)
  - Test: All apps
  - Deploy: If ANY app fails, ALL deployments block

Polyrepo Advantage:

# Products team deploys independently
products-pipeline:
  - Build: products only (3 minutes)
  - Test: products only
  - Deploy: products to CDN
  - ✅ No impact on other teams

# Cart team deploys at the same time
cart-pipeline:
  - Build: cart only (2 minutes)
  - Test: cart only
  - Deploy: cart to CDN
  - ✅ Completely independent

Real-world Impact:

Deployment frequency increased from 2-3 times/week to 10+ times/day
Build time per MFE: 2-5 minutes vs. 15-20 minutes for entire monorepo
Failed builds don't block other teams

3. Technology Flexibility 🛠️

While our current stack is Angular 18, polyrepo allows:

// Host: Angular 18
@Component({...})
export class HostApp {}

// Products MFE: Angular 18 + Latest Features
import { signal, computed } from '@angular/core';

// Cart MFE: Could use React (future flexibility)
// No impact on other MFEs as long as Module Federation contract is maintained

// Profile MFE: Could use Vue (if needed)
// Each MFE is truly independent

Real Example:
One team wanted to experiment with Angular's latest signal-based forms (experimental), while others preferred stable APIs. In polyrepo, this is trivial—each team controls their own package.json.

4. Granular Access Control 🔐

Enterprise Requirements:

# Financial services company scenario
products/          # Public team (20 developers)
cart/              # Public team (15 developers)
admin/             # Restricted (5 senior developers only)
analytics/         # Data team only (GDPR/compliance)

With separate repositories:

✅ GitHub permissions per repo
✅ Different security policies per MFE
✅ Audit trail per team
✅ Branch protection rules per team preference

5. Clearer Versioning & Dependencies 📦

Shared UI Kit Approach:

# Published as npm package
@hemantajax/mfe-uikit@1.2.3

// Products MFE (package.json)
{
  "dependencies": {
    "@hemantajax/mfe-uikit": "^1.2.0"
  }
}

// Cart MFE (package.json) - Can use different version
{
  "dependencies": {
    "@hemantajax/mfe-uikit": "^1.1.0"  // Still on older version
  }
}

Advantages:

✅ Semantic versioning for shared code
✅ Teams upgrade at their own pace
✅ No "big bang" upgrades across all apps
✅ Backward compatibility testing becomes explicit

⚖️ Trade-offs: The Honest Truth

Advantages of Polyrepo ✅

Aspect	Monorepo	Polyrepo
Team Autonomy	Low - Shared repo	High - Independent repos
Deployment Speed	Slow - Build everything	Fast - Build only what changed
Independent Deployments	Difficult	Easy
Technology Flexibility	Constrained	High
Access Control	Repository-level only	Per-MFE granular
CI/CD Pipeline	Single, complex	Multiple, simple
Version Management	Implicit via monorepo	Explicit via npm versions
Onboarding New Teams	One repo to clone	Multiple repos (more setup)
Team Scaling	Difficult beyond 20-30 devs	Easy to scale to 100+ devs

Disadvantages of Polyrepo ❌

1. More Complex Setup

Monorepo:

git clone mfeworld
npm install
nx serve dashboard  # Everything works

Polyrepo:

# Clone multiple repositories
git clone mfe-host
git clone mfe-uikit

# Each MFE team clones their own repo
git clone products
git clone cart
...

# Install dependencies in each
cd mfe-host && npm install
cd ../products && npm install
cd ../cart && npm install

Mitigation:

Use workspace management tools (meta, git submodules)
Provide setup scripts
Docker Compose for local development

# docker-compose.yml
services:
  host:
    build: ./mfe-host
    ports: ['4200:4200']
  products:
    build: ./products
    ports: ['4201:4201']
  cart:
    build: ./cart
    ports: ['4202:4202']

2. Shared Code Management

Monorepo:

// Direct imports, no publishing needed
import { HeaderComponent } from '@nxmfe/shared/layout';

Polyrepo:

// Must publish to npm/GitHub Packages
import { HeaderComponent } from '@hemantajax/mfe-uikit';

// Requires:
// 1. Build UI Kit
// 2. Publish to registry
// 3. Update version in consuming MFEs
// 4. npm install in each MFE

Mitigation:

Automated publishing via GitHub Actions
Semantic versioning
Changelog automation
Consider using Renovate Bot for dependency updates

# .github/workflows/publish-uikit.yml
name: Publish UI Kit
on:
  push:
    branches: [main]
jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: nx build uikit
      - run: npm publish dist/libs/uikit

3. Cross-Cutting Changes

Scenario: Update authentication logic across all MFEs

Monorepo:

# Single PR affects all apps
nx run-many --target=test --all    # Test everything
git commit -m "feat: update auth"  # One commit

Polyrepo:

# 1. Update UI Kit
cd mfe-uikit
# Make changes to AuthService
git commit -m "feat: update auth"
npm version minor  # 1.2.0 → 1.3.0
git push

# 2. Update each MFE (8 separate PRs!)
cd products
npm update @hemantajax/mfe-uikit@latest
git commit -m "chore: update uikit"

cd cart
npm update @hemantajax/mfe-uikit@latest
git commit -m "chore: update uikit"
# ... repeat for 6 more MFEs

Mitigation:

Automation scripts for bulk updates
Renovate Bot for automatic PR creation
Feature flags for gradual rollout
Backward compatible changes

4. Testing Integration

Monorepo:

# Easy to run integration tests
nx run-many --target=e2e --all

Polyrepo:

Need separate integration test repository
Must coordinate MFE versions
More complex CI/CD orchestration

Solution:

# Separate integration-tests repository
integration-tests/
  ├── tests/
  │   ├── user-journey.spec.ts     # Test across MFEs
  │   └── checkout-flow.spec.ts
  └── playwright.config.ts

# Uses deployed versions
playwright.config.ts:
  use: {
    baseURL: 'https://hemantajax.github.io/mfe-host/'
  }

5. Debugging Across Repositories

Monorepo:

Single IDE workspace
Easy to set breakpoints across apps
Cmd+Click to jump between files

Polyrepo:

Multiple IDE windows
Need to use npm link for local UI Kit development
Debugging shared code requires linking

Workflow:

# Develop UI Kit locally
cd mfe-uikit
npm link

# Link in consuming MFE
cd ../products
npm link @hemantajax/mfe-uikit

# Make changes, see updates in real-time
cd ../mfe-uikit
# Edit code → products automatically picks up changes

🏗️ Architecture Deep Dive

Module Federation Configuration

The magic that makes it all work:

Host Application (mfe-host):

// module-federation.config.prod.ts
export default {
  name: 'shell',
  remotes: [
    ['products', 'https://hemantajax.github.io/mfedemos/products/remoteEntry.mjs'],
    ['cart', 'https://hemantajax.github.io/mfedemos/cart/remoteEntry.mjs'],
    ['profile', 'https://hemantajax.github.io/mfedemos/profile/remoteEntry.mjs'],
    ['orders', 'https://hemantajax.github.io/mfedemos/orders/remoteEntry.mjs'],
    ['analytics', 'https://hemantajax.github.io/mfedemos/analytics/remoteEntry.mjs'],
    ['notifications', 'https://hemantajax.github.io/mfedemos/notifications/remoteEntry.mjs'],
    ['messages', 'https://hemantajax.github.io/mfedemos/messages/remoteEntry.mjs'],
    ['admin', 'https://hemantajax.github.io/mfedemos/admin/remoteEntry.mjs'],
  ],
};

Route Configuration:

// app.routes.ts
export const appRoutes: Route[] = [
  {
    path: 'products',
    loadChildren: () => import('products/Routes').then((m) => m.remoteRoutes),
  },
  {
    path: 'cart',
    loadChildren: () => import('cart/Routes').then((m) => m.remoteRoutes),
  },
  // ... other routes
];

Shared UI Kit Strategy

Publishing Workflow:

Single npm Package (@hemantajax/mfe-uikit)

Contains all shared components, services, utilities
Versioned independently
Published to GitHub Packages (or npm)

Internal Organization (in UI Kit repo)

mfe-uikit/
├── libs/
│   ├── layout/          # Header, Footer, Sidebar
│   ├── components/      # Buttons, Forms, Cards
│   ├── services/        # API, Auth, Storage
│   ├── utils/           # Helper functions
│   ├── pipes/           # Custom pipes
│   ├── directives/      # Custom directives
│   └── uikit/           # ⭐ Meta package (re-exports all)

Usage in MFEs:

// Before (monorepo):
import { HeaderComponent } from '@nxmfe/shared/layout';
import { AuthService } from '@nxmfe/shared/services';

// After (polyrepo):
import { HeaderComponent, AuthService } from '@hemantajax/mfe-uikit';

Benefits:

✅ Single version to manage
✅ One npm install command
✅ Simpler imports
✅ Can still organize code internally

📊 Real-World Metrics

Before (Monorepo)

Repository size: 500MB (with .git)
Full build time: 18 minutes
CI pipeline: 25 minutes
Deployments: 2-3 times per week
PR review time: 2-3 days (bottleneck)
Teams blocked: Often

After (Polyrepo)

Repository size: 50-80MB per repo
MFE build time: 2-5 minutes
CI pipeline per MFE: 5-8 minutes
Deployments: 10+ times per day (per team)
PR review time: Same day
Teams blocked: Never

🚀 When to Choose Polyrepo?

Choose Polyrepo When:

✅ You have multiple independent teams (3+ teams)

Each team owns specific features/domains
Teams want different release schedules
Teams are in different time zones

✅ You need independent deployments

Can't afford monorepo build times
Need to deploy hotfixes to single MFE
Different apps have different SLAs

✅ Enterprise requirements

Need granular access control
Compliance/security boundaries
Different teams have different tech stacks

✅ Scaling beyond 20-30 developers

PR bottlenecks in shared repo
Difficult to coordinate releases
CI/CD pipeline too complex

Choose Monorepo When:

✅ Small team (< 20 developers)

Everyone can review all PRs
Shared ownership model works
Coordinated releases are preferred

✅ Rapid prototyping

Quick iteration across multiple apps
Frequent refactoring of shared code
Atomic commits across apps are valuable

✅ Simple deployment

Can afford to build everything
Single deployment schedule works
Less infrastructure complexity

🛠️ Implementation Checklist

If you're migrating from monorepo to polyrepo:

Phase 1: Preparation

[ ] Identify team boundaries
[ ] Define shared code strategy
[ ] Set up package registry (npm, GitHub Packages)
[ ] Plan repository structure
[ ] Document architecture decisions

Phase 2: Extract Shared Code

[ ] Create UI Kit repository
[ ] Migrate shared libraries
[ ] Set up automated publishing
[ ] Test package installation
[ ] Document shared API

Phase 3: Split Micro-Frontends

[ ] Create repo for each MFE
[ ] Migrate code and dependencies
[ ] Set up individual CI/CD
[ ] Update Module Federation configs
[ ] Test remote loading

Phase 4: Update Host

[ ] Update remote URLs
[ ] Update production configs
[ ] Test integration
[ ] Set up monitoring
[ ] Document deployment process

Phase 5: Developer Experience

[ ] Create setup scripts
[ ] Write comprehensive docs
[ ] Set up local development workflow
[ ] Automate dependency updates
[ ] Train teams

🔧 Developer Experience Tips

1. Local Development Setup

Use npm link for UI Kit development:

# Terminal 1: UI Kit (watch mode)
cd mfe-uikit
npm run build:watch

# Terminal 2: Link UI Kit
cd mfe-uikit
npm link

# Terminal 3: Products MFE
cd products
npm link @hemantajax/mfe-uikit
npm start

2. Automated Dependency Updates

Renovate Bot Configuration:

{
  "extends": ["config:base"],
  "packageRules": [
    {
      "matchPackagePatterns": ["@hemantajax/mfe-uikit"],
      "groupName": "UI Kit",
      "automerge": true,
      "automergeType": "pr"
    }
  ]
}

3. Integration Testing

Separate test repository:

// integration-tests/tests/checkout.spec.ts
import { test, expect } from '@playwright/test';

test('complete checkout flow', async ({ page }) => {
  // Navigate to host
  await page.goto('https://hemantajax.github.io/mfe-host/');

  // Interact with products MFE
  await page.goto('/products');
  await page.click('[data-testid="add-to-cart"]');

  // Interact with cart MFE
  await page.goto('/cart');
  await expect(page.locator('[data-testid="cart-item"]')).toBeVisible();

  // Interact with orders MFE
  await page.click('[data-testid="checkout"]');
  await page.goto('/orders');
  await expect(page.locator('[data-testid="order-success"]')).toBeVisible();
});

📚 Resources

Live Demo & Source Code

Demo: https://hemantajax.github.io/mfe-host/
Host Repo: https://github.com/hemantajax/mfe-host
UI Kit Repo: https://github.com/hemantajax/mfe-uikit

Remote MFEs (Deployed)

Products: https://hemantajax.github.io/mfedemos/products/
Cart: https://hemantajax.github.io/mfedemos/cart/
Profile: https://hemantajax.github.io/mfedemos/profile/
Orders: https://hemantajax.github.io/mfedemos/orders/
Analytics: https://hemantajax.github.io/mfedemos/analytics/
Notifications: https://hemantajax.github.io/mfedemos/notifications/
Messages: https://hemantajax.github.io/mfedemos/messages/
Admin: https://hemantajax.github.io/mfedemos/admin/

Building Scalable Applications with Micro-Frontends (Monorepo)

🎯 Conclusion

The shift from monorepo to polyrepo wasn't just about technology—it was about empowering teams to work independently while maintaining a cohesive architecture.

Key Takeaways:

Polyrepo isn't inherently better than monorepo—it's a trade-off based on team size and organizational needs
Start with monorepo if you're a small team or prototyping—the simplicity is worth it
Migrate to polyrepo when team boundaries become clear and independent deployments become critical
Invest in tooling to mitigate polyrepo complexity (automation, scripts, docs)
Module Federation makes polyrepo micro-frontends feasible—without it, this architecture would be painful

What Would I Do Differently?

Looking back, I would:

Create the UI Kit earlier - Even in monorepo, a separate UI Kit would have helped with versioning
Automate more - Set up Renovate Bot and deployment automation from day one
Better documentation - Invest in comprehensive setup guides before splitting repos
Integration tests first - Have strong integration test coverage before splitting

💬 Discussion

What's your experience with monorepo vs. polyrepo? Have you tried micro-frontends in your organization?

I'd love to hear about:

What challenges did you face?
What would you do differently?
Any tips for teams considering this architecture?

Drop a comment below! 👇

Follow me for more:

Twitter: @hemantajax
GitHub: @hemantajax
LinkedIn: Hemant Singh

Tags: #microfrontends #angular #architecture #modulefederation #webpack #nx #monorepo #polyrepo #webdev #javascript #typescript #frontend

This article is based on real production experience migrating a medium-sized team from monorepo to polyrepo architecture. All code examples and demos are available in the linked repositories.

Building Scalable Applications with Micro-Frontends: A Practical Guide

Hemant Singh — Mon, 20 Oct 2025 10:13:03 +0000

Deployment structure ( MFE Demo ):

Host: https://hemantajax.github.io/mfedemos/
Remotes:
• products: https://hemantajax.github.io/mfedemos/products/

• cart: https://hemantajax.github.io/mfedemos/cart/

• profile: https://hemantajax.github.io/mfedemos/profile/

• orders: https://hemantajax.github.io/mfedemos/orders/

• analytics: https://hemantajax.github.io/mfedemos/analytics/

• notifications: https://hemantajax.github.io/mfedemos/notifications/

• messages: https://hemantajax.github.io/mfedemos/messages/

• admin: https://hemantajax.github.io/mfedemos/admin/

Introduction

In today's fast-paced development landscape, building scalable and maintainable applications is crucial. Micro-frontends extend the microservices concept to frontend development, allowing teams to work independently while delivering a unified user experience.

In this article, I'll share a practical approach to building micro-frontend applications using Angular 20, Module Federation, and Nx Workspace.

🎯 What You'll Learn

Creating a Host (Shell) application
Building Remote micro-frontend applications
Local development setup
Production deployment strategy
Sharing services across micro-frontends

🏗️ Architecture Overview

A micro-frontend architecture consists of:

Host Application (Shell): The main application that orchestrates everything
Remote Applications: Independent micro-frontends loaded dynamically
Shared Libraries: Common code, utilities, and services

The diagram above shows how the Host (Shell) application dynamically loads multiple remote micro-frontends, all sharing common services and state management.

📦 Step 1: Creating the Host Application

// one time only
npx nx g @nx/angular:setup-mf mfeui --mfType=host --port=4200

The host application is your main shell that loads remote micro-frontends dynamically.

Module Federation Config (Host)

// module-federation.config.ts
module.exports = {
  name: 'mfeui',
  remotes: {
    products: 'http://localhost:4201',
    cart: 'http://localhost:4202',
    profile: 'http://localhost:4203',
    orders: 'http://localhost:4204',
  },
};

Routing Configuration

// app.routes.ts
export const appRoutes: Route[] = [
  {
    path: 'products',
    loadChildren: () => import('products/Routes').then((m) => m.remoteRoutes),
  },
  {
    path: 'cart',
    loadChildren: () => import('cart/Routes').then((m) => m.remoteRoutes),
  },
  // ... more routes
];

🔧 Step 2: Creating Remote Applications

npx nx g @nx/angular:remote apps/<remote-name> --host=mfeui --port=<PORT> --style=scss

// Ex.
npx nx g @nx/angular:remote apps/products --host=mfeui --port=4201 --style=scss

npx nx g @nx/angular:remote apps/cart --host=mfeui --port=4202 --style=scss

Each remote is an independent Angular application that can be developed, tested, and deployed separately.

Module Federation Config (Remote)

// module-federation.config.ts (products remote)
module.exports = {
  name: 'products',
  exposes: {
    './Routes': 'apps/products/src/app/remote-entry/entry.routes.ts',
  },
};

Remote Entry Component

// remote-entry.component.ts
@Component({
  selector: 'app-products-entry',
  template: `
    <div class="container mt-4">
      <h2>Products Micro-Frontend</h2>
      <router-outlet></router-outlet>
    </div>
  `,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class RemoteEntryComponent {}

💻 Local Development

Running your micro-frontends locally is straightforward:

Start Individual Applications

# Terminal 1 - Host
nx serve mfeui --port 4200

# Terminal 2 - Products Remote
nx serve products --port 4201

# Terminal 3 - Cart Remote
nx serve cart --port 4202

Start All at Once

# Use the development script
npm start

# This runs all applications concurrently:
# - Host (mfeui): http://localhost:4200
# - Products: http://localhost:4201
# - Cart: http://localhost:4202
# - Profile: http://localhost:4203
# - Orders: http://localhost:4204
# - Analytics: http://localhost:4205
# - Notifications: http://localhost:4206
# - Messages: http://localhost:4207
# - Admin: http://localhost:4208

The host will automatically load remotes from their respective ports during development.

🚀 Production Deployment

For production, the configuration changes to use absolute URLs:

Production Module Federation Config

// module-federation.config.prod.ts
module.exports = {
  name: 'mfeui',
  remotes: {
    products: 'https://hemantajax.github.io/mfedemos/products/',
    cart: 'https://hemantajax.github.io/mfedemos/cart/',
    profile: 'https://hemantajax.github.io/mfedemos/profile/',
    orders: 'https://hemantajax.github.io/mfedemos/orders/',
    analytics: 'https://hemantajax.github.io/mfedemos/analytics/',
    notifications: 'https://hemantajax.github.io/mfedemos/notifications/',
    messages: 'https://hemantajax.github.io/mfedemos/messages/',
    admin: 'https://hemantajax.github.io/mfedemos/admin/',
  },
};

Build for Production

# Build host
nx build mfeui --configuration=production

# Build remotes
nx build products --configuration=production
nx build cart --configuration=production
# ... etc

Deployment Structure

https://hemantajax.github.io/mfedemos/
├── index.html (Host)
├── products/
│   └── remoteEntry.js
├── cart/
│   └── remoteEntry.js
├── profile/
│   └── remoteEntry.js
└── ...

🔄 Sharing Services Across Micro-Frontends

One of the most powerful features is sharing state and services across micro-frontends. This is where the magic happens!

Shared Service Architecture

// libs/shared/services/src/lib/state.service.ts
import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class StateService {
  // Shared state using Angular signals
  private cartItemsSignal = signal<number>(0);

  cartItems = this.cartItemsSignal.asReadonly();

  addToCart(): void {
    this.cartItemsSignal.update((count) => count + 1);
  }

  removeFromCart(): void {
    this.cartItemsSignal.update((count) => Math.max(0, count - 1));
  }
}

Using Shared Services

In Products Remote:

export class ProductListComponent {
  private stateService = inject(StateService);

  addToCart(product: Product): void {
    // Add product logic...
    this.stateService.addToCart();
  }
}

In Cart Remote:

export class CartComponent {
  private stateService = inject(StateService);

  cartItems = this.stateService.cartItems;

  removeItem(item: CartItem): void {
    // Remove item logic...
    this.stateService.removeFromCart();
  }
}

In Host Navigation:

export class NavbarComponent {
  private stateService = inject(StateService);

  cartCount = this.stateService.cartItems;
}

Real-World Example

For a complete guide on implementing shared services with state management, event communication, and best practices, check out:

📚 Shared Services Guide

This guide covers:

✅ State management across micro-frontends
✅ Event-driven communication
✅ Service singleton patterns
✅ Best practices and gotchas

📊 Benefits We've Achieved

1. Independent Development

Teams work on separate micro-frontends without conflicts
Each team owns their deployment pipeline

2. Scalability

Add new features as new micro-frontends
Scale teams independently

3. Technology Flexibility

Different versions of Angular (if needed)
Different UI libraries per micro-frontend
Gradual migration capabilities

4. Performance

Lazy loading of micro-frontends
Load only what users need
Reduced initial bundle size

5. Maintainability

Smaller codebases per micro-frontend
Easier to understand and modify
Better test coverage

🎓 Key Takeaways

Start Simple: Begin with a host and 2-3 remotes
Shared Libraries: Create shared code for common functionality
Service Communication: Use singleton services for cross-micro-frontend communication
Environment Configs: Separate configs for local and production
Documentation: Keep your architecture documented (crucial for team onboarding)

🔗 Live Demo & Source Code

Want to see it in action?

🌐 Live Demo: https://hemantajax.github.io/mfedemos/

💻 Source Code: https://github.com/hemantajax/mfedemos

Explore the Documentation:

💬 Final Thoughts

Micro-frontends are not just about splitting code – they're about enabling team autonomy, improving scalability, and creating a more maintainable architecture.

The learning curve is worth it, especially for large-scale applications with multiple teams.

DEV Community: Hemant Singh

From Monorepo to Polyrepo: Scaling Micro-Frontends Across Teams

From Monorepo to Polyrepo: Scaling Micro-Frontends Across Teams

Introduction

🎯 The Journey: From Monorepo to Polyrepo

Previous Approach: Monorepo

New Approach: Polyrepo

🤔 Why Polyrepo? The Business Case

1. Team Autonomy & Ownership 🎯

2. Independent Deployment Pipeline 🚀

3. Technology Flexibility 🛠️

4. Granular Access Control 🔐

5. Clearer Versioning & Dependencies 📦

⚖️ Trade-offs: The Honest Truth

Advantages of Polyrepo ✅

Disadvantages of Polyrepo ❌

1. More Complex Setup

2. Shared Code Management

3. Cross-Cutting Changes

4. Testing Integration

5. Debugging Across Repositories

🏗️ Architecture Deep Dive

Module Federation Configuration

Shared UI Kit Strategy

📊 Real-World Metrics

Before (Monorepo)

After (Polyrepo)

🚀 When to Choose Polyrepo?

Choose Polyrepo When:

Choose Monorepo When:

🛠️ Implementation Checklist

Phase 1: Preparation

Phase 2: Extract Shared Code

Phase 3: Split Micro-Frontends

Phase 4: Update Host

Phase 5: Developer Experience

🔧 Developer Experience Tips

1. Local Development Setup

2. Automated Dependency Updates

3. Integration Testing

📚 Resources

Live Demo & Source Code

Remote MFEs (Deployed)

Related Articles

🎯 Conclusion

Key Takeaways:

What Would I Do Differently?

💬 Discussion

Building Scalable Applications with Micro-Frontends: A Practical Guide

Deployment structure ( MFE Demo ):

Introduction

🎯 What You'll Learn

🏗️ Architecture Overview

📦 Step 1: Creating the Host Application

Module Federation Config (Host)

Routing Configuration

🔧 Step 2: Creating Remote Applications

Module Federation Config (Remote)

Remote Entry Component

💻 Local Development

Start Individual Applications

Start All at Once

🚀 Production Deployment

Production Module Federation Config

Build for Production

Deployment Structure

🔄 Sharing Services Across Micro-Frontends

Shared Service Architecture

Using Shared Services

Real-World Example

📊 Benefits We've Achieved

1. Independent Development

2. Scalability

3. Technology Flexibility

4. Performance

5. Maintainability

🎓 Key Takeaways

🔗 Live Demo & Source Code

Explore the Documentation:

💬 Final Thoughts