Module 7: When NOT to Use Micro Frontend Architecture

When NOT to Use Micro Frontend Architecture

Avoid Micro Frontends when:

• The project is small or medium - Complexity not justified
• There is only one team - No team autonomy needed
• Simplicity and speed matter most - Overhead too high
• Infrastructure maturity is low - Setup too complex

In these cases, traditional Angular with lazy loading is more effective.

When to Avoid

1. Small Projects

Avoid if:

• ❌ < 20 components
• ❌ < 10,000 lines of code
• ❌ Single developer or small team
• ❌ Proof of concept or MVP

Use instead:

• ✅ Traditional Angular app
• ✅ Lazy loading for code splitting
• ✅ Simple deployment

2. Single Team

Avoid if:

• ❌ One team works on everything
• ❌ Tight collaboration required
• ❌ No team boundaries
• ❌ Coordinated releases work

Use instead:

• ✅ Monolithic Angular app
• ✅ Shared codebase
• ✅ Simple coordination

3. Tight Integration Required

Avoid if:

• ❌ Features heavily interdependent
• ❌ Shared state critical
• ❌ Real-time collaboration needed
• ❌ Tight coupling intentional

Use instead:

• ✅ Monolithic app
• ✅ Shared modules
• ✅ Direct component communication

4. Short-Term Projects

Avoid if:

• ❌ Project lifetime < 1 year
• ❌ Proof of concept
• ❌ Temporary solution
• ❌ Learning project

Use instead:

• ✅ Simple Angular app
• ✅ Quick iteration
• ✅ Minimal setup

5. Low Infrastructure Maturity

Avoid if:

• ❌ No CI/CD experience
• ❌ Limited DevOps resources
• ❌ No containerization
• ❌ Simple hosting only

Use instead:

• ✅ Traditional deployment
• ✅ Single build pipeline
• ✅ Simple hosting

Cost of Complexity

Micro Frontend Overhead

• Setup time: 2-4 weeks
• Infrastructure: Additional servers/CDN
• Debugging: More complex
• Testing: More complex
• Documentation: More required

When Overhead > Benefits

If your project doesn't have:

• ✅ Large team (> 10 developers)
• ✅ Long-term maintenance (> 2 years)
• ✅ Independent deployments needed
• ✅ Clear domain boundaries

Then the overhead is not justified.

Alternative: Lazy Loading

Traditional Angular with Lazy Loading

const routes: Routes = [
  {
    path: 'products',
    loadChildren: () => import('./products/products.module')
      .then(m => m.ProductsModule)
  },
  {
    path: 'checkout',
    loadChildren: () => import('./checkout/checkout.module')
      .then(m => m.CheckoutModule)
  }
]

Benefits

• ✅ Code splitting
• ✅ Lazy loading
• ✅ Simple setup
• ✅ No infrastructure overhead

When It's Enough

• ✅ Single team
• ✅ Coordinated deployments OK
• ✅ Shared codebase acceptable
• ✅ Simple architecture sufficient

Real-World Anti-Patterns

Anti-Pattern 1: Over-Engineering

Problem:

• Small team uses Micro Frontends
• 3 developers, 1 application
• Unnecessary complexity

Solution:

• Use traditional Angular
• Lazy loading for code splitting
• Simple deployment

Anti-Pattern 2: Premature Optimization

Problem:

• "We might scale later"
• No current scaling issues
• Adding complexity "just in case"

Solution:

• Start simple
• Migrate when needed
• Don't optimize prematurely

Anti-Pattern 3: Technology Fetish

Problem:

• "Micro Frontends are cool"
• No real need
• Following trends

Solution:

• Choose based on needs
• Not on trends
• Evaluate objectively

Decision Framework

Ask These Questions

1. Team Size?

• < 5 → Avoid
• 5-10 → Consider
• > 10 → Strong candidate

1. Project Lifetime?

• < 1 year → Avoid
• 1-2 years → Consider
• > 2 years → Strong candidate

1. Deployment Needs?

• Coordinated OK → Avoid
• Some independence → Consider
• Full independence → Strong candidate

1. Domain Boundaries?

• Tightly coupled → Avoid
• Some boundaries → Consider
• Clear boundaries → Strong candidate

The Golden Rule

If you're not sure, start simple.

You can always migrate to Micro Frontends later.

You cannot easily simplify a Micro Frontend architecture.

Summary

Avoid Micro Frontends when:

• ❌ Small project
• ❌ Single team
• ❌ Short-term
• ❌ Low infrastructure maturity
• ❌ Tight integration needed

Use traditional Angular when:

• ✅ Simplicity matters
• ✅ Speed matters
• ✅ Small team
• ✅ Simple deployment sufficient

The next module shows the project architecture we'll build.